Raft lecture (Raft user study)

One of the most lucid explanations of the Raft Consensus Algorithm that I've ever seen is the one in John Ousterhout and Diego Ongaro's Raft User Study[0]. The 2 videos do an excellent job of explaining both the Paxos and Raft algorithms and the key differences between them. John's narration is extremely clear and the slides are very informative. Definitely recommended! Raft is a consensus algorithm designed to be easier to understand than Paxos. To measure Raft's understandability, we conducted an experimental study using CS students at two universities. We recorded a video lecture of Raft and another of Paxos, and created corresponding quizzes. This page makes our materials available for anyone interested. We think these are valuable resources for anyone learning consensus (whether Raft or Paxos or both). [0] - link Raft Video - ▶ this video Paxos Video - link

This YouTube video by the Raft creators (linked at the bottom of the page) gives a solid explanation of Raft internals - ▶ this video

A really good intro to Raft --> ▶ this video Very useful if you are into distributed systems and would like to see a practical implementation with clear examples.

one other thing to keep in mind is that the underlying algorithms (zab and raft) provide different guarantees. for example, zookeeper/zab allows reading directly from followers with a guarantee to get at least a past value that won't be rolled back. this was one reason zookeer didn't use paxos: link in my understanding, raft doesn't allow reading directly from followers, because the follower logs may get repaired/rolled-back when a new leader is elected. (though i'm sure an implementation can tweak the protocol to provide this support.) that said, raft has a lot of interesting applications, and, in my opinion, is definitely more understandable than the many versions of paxos. (implementing zab yourself, at this point, would be a futile exercise.) i found the videos from the raft user study to be very well done (and easier to understand than even their paper): raft: link paxos: ▶ this video ...however, i think they did paxos a disadvantage by not just focusing on multi-paxos (which is probably the most common implementation). but, it's certainly fair to say that info about paxos is spread out far and wide...with perhaps too many knobs to turn and implementation-related details to fill in yourself. as a side note: i've just started implementing raft in a set of libraries (multiple languages) that will be open source - along with other protocols.

Raft is very similar to Multi-Paxos. These Raft and Paxos user studies comparing the "understandability" of the two protocols might be helpful: link (Paxos), ▶ this video (Raft). See also, comparison of various "Paxos" implementations: link

This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities). [edit: specifying the population of a study is pretty important. Getting random students from the University to approve your security patch doesn't make sense. Picking students who successfully completed a computer security course and got a high grade is better than that but again, may not generalize to the real world. One of the most impressive ways I have seen this being done by grad students was a user study by John Ousterhout and others on Paxos vs. Raft. IIRC, they wanted to claim that Raft was more understandable or led to fewer bugs. Their study design was excellent. See here for an example: ▶ this video ]

> and does not address the situation of two nodes having conflicting sets of data (for instance from network partition). I believe it does address this. Each log entry is either committed or not; an entry can only be committed if it has been replicated to a majority of nodes. Any node that lacks a committed entry cannot be elected master because of the election rules: a node will not vote for another node less complete than itself. Since a committed entry has been replicated to a majority, a node lacking that entry cannot receive a majority of the votes. (Thus the committed log entries will always be the same on all nodes (though some may be behind, and may only have a subset), which is the purpose of the protocol.) > Considering it basically relies on random chance (I.E. who receives the message first) to elect a master, has basically no real way of resolving a conflict in election This is mostly true. The PDF slides I link to below recommend that the election timeout be much greater than the broadcast time, the idea being that things should work out in the long run. Highly recommend the PDF slides here, as they explain it better than I can: link — there's also a YouTube talk here: ▶ this video > Considering all that, this protocol doesn't seem very interesting (from a use-case point of view). I'd love to hear of alternatives.

Consider doing some language processing using the excellent NLTK library: link It wasn't on the lists of "wants", but implementing the Raft consensus protocol could be neat too. It was designed to be understandable and implementable. The video is here: ▶ this video . The research paper is here: link

i don't think this is the case. here is a link to a video by one of the authors about log repair during leader election: ▶ this video log entries on a follower may get rolled back - and thrown out - since they were not accepted on a majority of followers.