4 ms·

Here is their answer to their own question - "What is Raft?" >Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos

Here is their answer to their own question - "What is Raft?" >Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos in fault-tolerance and performance. The difference is that it's decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems. We hope Raft will make consensus available to a wider audience, and that this wider audience will be able to develop a variety of higher quality consensus-based systems than are available today. After reading that I still have no idea. They are not alone in doing this, but I think its a shame that people don't spend the extra time and effort in properly describing their work.

BirdieNZ 3y ago
Arguably it's a good description because it automatically filters out audiences who don't know what it means; if you're building a distributed system and looking at different consensus algorithms then it's a simple and clear explanation, but if you aren't then it's not a relevant algorithm for you anyway! The general class of consensus algorithms are for trying to solve the problem of what to do when you have multiple replicas of a data store across several physical devices, when one or many of the devices or their connections fail in some fashion. They are titled "consensus" because the machines need to come to a consensus for what decision to make about a piece of data when a failure event occurs. For example, you have three servers all replicating the same SQL database: (A) - (B) - (C) The network connection linking (C) to the other two drops; (A) and (B) are notified and (B) is promoted to be the primary (it receives the writes and then distributes them to the replicas). However, (C) doesn't know what's happened, and continues to receive some writes. The network connection is restored, and now (A) and (B) and (C) need to decide what to do. (B) and (C) have both independently received a different set of writes, and the servers need to come to a consensus on what to do with the data. This is what Raft, Paxos etc. are attempting to solve in a consistent and performant fashion.
- beachy 3y ago
  > Arguably it's a good description because it automatically filters out audiences who don't know what it means; if you're building a distributed system and looking at different consensus algorithms then it's a simple and clear explanation, but if you aren't then it's not a relevant algorithm for you anyway! Somewhat discourteous to the 99% of people who don't fall into the target audience - you're leaving it to them to thrash around until they work out for themselves they're at the wrong bar.
- rcxdude 3y ago
  This isn't really what Raft is used for: conflict resolution is a completely different area of distributed systems (and, unless you have specifically designed your application for this, the situation you describe where C continues to accept writes when the rest of the system has reached a new consensus would be considered a 'split-brain' failure, the kind of thing which tends to get you roasted by Jepsen tests). Raft is used to avoid the conflicts in the first place: the idea is for A, B, and C to agree on some state, or know that no consensus has been made (or at least, that if it has been made, they do not know it and therefore should not act on that information). So in your example it would be used to make sure that A, B, and C agree on the primary initially, and when C is not able to communicate to the others that it does not accept writes. (and in general in high-volume applications like most databases they do not run a consensus on each write, but instead use the consensus as part of their overall strategy for consistency, e.g. through deciding on a leader node).
oasisaimlessly 3y ago
Did you try reading the next paragraph ("Hold on—what is consensus?")? Sometimes concepts are too "big" to be introduced to someone with no background in a single paragraph; such is life. However, the linked article is a great intro if you manage to keep reading.

BirdieNZ 3y ago

Arguably it's a good description because it automatically filters out audiences who don't know what it means; if you're building a distributed system and looking at different consensus algorithms then it's a simple and clear explanation, but if you aren't then it's not a relevant algorithm for you anyway! The general class of consensus algorithms are for trying to solve the problem of what to do when you have multiple replicas of a data store across several physical devices, when one or many of the devices or their connections fail in some fashion. They are titled "consensus" because the machines need to come to a consensus for what decision to make about a piece of data when a failure event occurs. For example, you have three servers all replicating the same SQL database: (A) - (B) - (C) The network connection linking (C) to the other two drops; (A) and (B) are notified and (B) is promoted to be the primary (it receives the writes and then distributes them to the replicas). However, (C) doesn't know what's happened, and continues to receive some writes. The network connection is restored, and now (A) and (B) and (C) need to decide what to do. (B) and (C) have both independently received a different set of writes, and the servers need to come to a consensus on what to do with the data. This is what Raft, Paxos etc. are attempting to solve in a consistent and performant fashion.

beachy 3y ago
> Arguably it's a good description because it automatically filters out audiences who don't know what it means; if you're building a distributed system and looking at different consensus algorithms then it's a simple and clear explanation, but if you aren't then it's not a relevant algorithm for you anyway! Somewhat discourteous to the 99% of people who don't fall into the target audience - you're leaving it to them to thrash around until they work out for themselves they're at the wrong bar.
rcxdude 3y ago
This isn't really what Raft is used for: conflict resolution is a completely different area of distributed systems (and, unless you have specifically designed your application for this, the situation you describe where C continues to accept writes when the rest of the system has reached a new consensus would be considered a 'split-brain' failure, the kind of thing which tends to get you roasted by Jepsen tests). Raft is used to avoid the conflicts in the first place: the idea is for A, B, and C to agree on some state, or know that no consensus has been made (or at least, that if it has been made, they do not know it and therefore should not act on that information). So in your example it would be used to make sure that A, B, and C agree on the primary initially, and when C is not able to communicate to the others that it does not accept writes. (and in general in high-volume applications like most databases they do not run a consensus on each write, but instead use the consensus as part of their overall strategy for consistency, e.g. through deciding on a leader node).

oasisaimlessly 3y ago

Did you try reading the next paragraph ("Hold on—what is consensus?")? Sometimes concepts are too "big" to be introduced to someone with no background in a single paragraph; such is life. However, the linked article is a great intro if you manage to keep reading.