HackerTube
HomeLongsLikedHistoryWatch laterCategoriesPlaylistsSettings

Raft lecture (Raft user study)

Diego Ongaro4 HN recommenders · recommended in 4 months, 2013-2025
YouTube
87K views · 13 years ago · lecture · evergreen

John Ousterhout lectures on the Raft consensus algorithm, made for the Raft user study comparing how students learn Raft and Paxos. It covers leader election and log repair.

HN commenters recommend it as a clearer introduction to Raft than the paper and as part of a well-designed understandability study.

Distributed systemsUniversity lectures & courses#raft#paxos#leaderelection#johnousterhout#distributedsystems

9 comments from Hacker News

@sathish3162025 · in “The Raft Consensus Algorithm (2015)”

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

RecommendsView on HN
@ignoramous2021 · in “Paxos vs. Raft: Have we reached consensus on distributed consensus?”

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

CitesView on HN
@throwawaybbq12021 · in ““They introduce kernel bugs on purpose””

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 ]

CitesView on HN
@krat0sprakhar2014 · in “The Raft Consensus Algorithm”

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

Strongly recommendsView on HN
@nieksand2014 · in “Ask HN: Final year project in CS”

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

CitesView on HN
@deathanatos2014 · in “Raft: Understandable Distributed Consensus”

> 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.

CitesView on HN
@pkj2013 · in “The Writings of Leslie Lamport”

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.

RecommendsView on HN
@tomjohnson32013 · in “ZooKeeper vs. Doozer vs. Etcd”

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.

CitesView on HN
@tomjohnson32013 · in “ZooKeeper vs. Doozer vs. Etcd”

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.

RecommendsView on HN
Paxos lecture (Raft user study)1:06:34

Paxos lecture (Raft user study)

Diego Ongaro
114K views • 13 years ago
Lecture 1: Introduction1:19:35

Lecture 1: Introduction

MIT 6.824: Distributed Systems
921K views • 6 years ago
Liberating Distributed Consensus - Heidi Howard34:52

Liberating Distributed Consensus - Heidi Howard

Reactive Summit
7K views • 7 years ago
Distributed Systems 1.1: Introduction14:36

Distributed Systems 1.1: Introduction

Martin Kleppmann
382K views • 6 years ago
AWS re:Invent 2014 | (SPOT302) Under the Covers of AWS: Its Core Distributed Systems46:15

AWS re:Invent 2014 | (SPOT302) Under the Covers of AWS: Its Core Distributed Systems

Amazon Web Services
10K views • 11 years ago
Differential Synchronization54:44

Differential Synchronization

Google TechTalks
52K views • 17 years ago
"Systems that run forever self-heal and scale" by Joe Armstrong (2013)1:10:23

"Systems that run forever self-heal and scale" by Joe Armstrong (2013)

Strange Loop Conference
85K views • 5 years ago
Google I/O 2012 - Go Concurrency Patterns51:27

Google I/O 2012 - Go Concurrency Patterns

Google for Developers
894K views • 14 years ago
CRDTs and the Quest for Distributed Consistency43:39

CRDTs and the Quest for Distributed Consistency

InfoQ
68K views • 8 years ago
Mastering Chaos - A Netflix Guide to Microservices53:14

Mastering Chaos - A Netflix Guide to Microservices

InfoQ
2.3M views • 9 years ago
Building Software Systems At Google and Lessons Learned1:22:45

Building Software Systems At Google and Lessons Learned

Stanford
257K views • 15 years ago
The Stellar Consensus Protocol | David Mazières | Talks at Google57:39

The Stellar Consensus Protocol | David Mazières | Talks at Google

Talks at Google
56K views • 10 years ago
Lamport on writing "Time, Clocks, and the Ordering of Events in a Distributed System"7:27

Lamport on writing "Time, Clocks, and the Ordering of Events in a Distributed System"

Turing Awardee Clips
24K views • 6 years ago
Solid Ground // Saša Jurić35:15

Solid Ground // Saša Jurić

EMPEX Conference
14K views • 9 years ago
"I See What You Mean" by Peter Alvaro52:29

"I See What You Mean" by Peter Alvaro

Strange Loop Conference
59K views • 11 years ago
Seattle Conference on Scalability: YouTube Scalability52:41

Seattle Conference on Scalability: YouTube Scalability

Google TechTalks
30K views • 19 years ago
Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt1:06:45

Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt

Erlang Solutions
13K views • 7 years ago
"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson40:20

"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson

Strange Loop Conference
55K views • 12 years ago
Matrix 2.0 — How we're making Matrix go voom!48:45

Matrix 2.0 — How we're making Matrix go voom!

Matrixdotorg
16K views • 3 years ago
Zach Tellman - Everything Will Flow40:13

Zach Tellman - Everything Will Flow

ClojureTV
27K views • 11 years ago