Check out Alex Miller's Data Replication Design Spectrum for what you might use instead of Raft (for replication specifically), or what tweaks you might make to Raft for better throughput or space efficiency (for replication).
Here's a recent Raft story from when I was trying to learn how to use it. I'm working on coding a multiplayer io game for fun. One key part was that it needs replication of game state so that live games can fail over if one of the servers crashes or is restarted.
I was like, "wait, that's what raft does, and my game state is already a state machine ... let's do this thing". I then ended up putting my entire game state into raft, and even abused it as a generic pubsub engine.
It was fun, and it worked, and was actually not hard to setup using the Rust implementation.
Then when I was done, I realized how pathological it was to put literally all game state and every single event into Raft, so decided to stop indulging myself by having fun and trying to hack Raft into an unintended use case, and just used Redis for game state and pubsub.
I never load tested the Raft implementation, but once I do have some perf testing tools, I'd be interesting to run the Raft code vs. Redis comparison to see how throughput differs. For this use case, at some point Raft should fall over while Redis would be chugging along.
chucky_z 9 hours ago [-]
It depends!!! If you do something like Consul does where you cram “events” into a radix tree that you send as one big batch it should scale quite well. I wouldn’t expect batched Redis performance but it should be within 70-80% of it in my guess.
blast 8 hours ago [-]
> I'm working on coding a multiplayer io game for fun.
I know what a multiplayer game is, but what's a multiplayer io game?
(not being snarky, i loved your comment)
ChadNauseam 7 hours ago [-]
There's a trend of "io games" which are so named because the first one was hosted on a site called "agar.io". then was followed by slither.io and so on. They are characterized by a few distinctive qualities: they're entirely browser-based, players are instantly dropped into a big lobby with tons of other players, they typically have simplistic graphics (e.g. powered by canvas), they have no long-term progression (once you die you restart from the beginning), and they have some kind of leaderboard where you can see the players in your shard that have progressed the farthest since the last time they died.
lopatin 7 hours ago [-]
It's just a browser based multi-player game with a .io TLD. Hope to make a Show HN soon :)
jorangreef 2 hours ago [-]
Raft played a huge role in improving how consensus is taught, compared to Paxos.
It’s hinted at in the introduction to the Raft paper, that Raft is "most notably" similar to Viewstamped Replication from Brian Oki, Barbara Liskov and James Cowling at MIT. Reason being that Raft’s primary goal was not so much to reinvent or contribute consensus, so much as to repackage consensus to be "more understandable than Paxos". Nevertheless, it’s not widely known, and probably could be emphasized a bit more, that the protocol is otherwise pretty much ‘88 Oki VSR (same essential protocol, different terms), itself predating Paxos a year.
For example, if you compare '14 Raft (Stanford) with '12 VSR (MIT’s revision to their ‘88 original), the resemblance is striking:
Presentation aside, the only major difference is that Raft’s view change (called leader election in the Raft paper) preserves the flavor of Oki’s ‘88 Viewstamped Replication view change, electing the candidate with the longest log, and missing out on the improved round-robin view change from MIT in ‘12, that brings better stability and availability, with lower latency, and no dueling leaders.
Raft has had a tremendous impact, compared to Paxos, in helping engineers to understand consensus. But once the training wheels are there, it’s important that we also understand and preserve the history of consensus, the people who pioneered these protocols.
[1] It's an accident of history that '12 VSR wasn't promoted as much as Raft would be, two years later. Otherwise, '12 VSR from James Cowling is arguably just as understandable, if not more. For example, because of the improved view change, the paper can begin immediately with normal replication. And there's no discussion, for example, of the need for randomized timeouts, it's elegantly designed away.
avinassh 1 hours ago [-]
one more difference I would add is how a leader is elected in Raft (randomized) vs VSR (deterministic succession)
jorangreef 1 hours ago [-]
Yes, exactly. That difference came in with '12 VSR's view change (deterministic, round-robin), which upgraded '88 VSR's view change.
'14 Raft missed this upgrade, unfortunately (despite citing the '12 paper), thus preserving Oki's '88 "pick the candidate with longest log".
I find the history of consensus fascinating, and was fortunate to interview both Brian Oki and James Cowling (so many anecdotes): https://www.youtube.com/watch?v=ps106zjmjhw
Both the Raft algorithm and its explanation are excellent, including this little animated demo that Diego Ongaro (who is also a great guy) made to help explain his invention. While Paxos was first and still popular, I am not sure I would count against any senior engineer unable to explain it to others. With Raft, one ought to be able to do it.
Great to see this on HN.
crdrost 10 hours ago [-]
I just want to clarify that, strictly speaking, Paxos is simpler than Raft. Like Paxos is Raft plus "delete the part where the new leader has to be fully caught-up" (which causes an extra weirdness in Raft when the leader got majority adoption of a new log entry but failed to commit it due to network partition) plus "delete the part where the leader election elects the leader, you can do that and it's called multi-paxos, but if your use case isn't big enough you can instead just elect the next log entry, but it doesn't have to have the form "this is our new leader, all hail" (but in practice this is what everyone does).
I think the Raft paper is more approachable for newcomers, but if you are finding Paxos hard to explain and Raft easy to explain, just use the Raft lingo to explain Paxos.
chc4 10 hours ago [-]
It is darkly amusing to me that Paxos is still cited by people as a "good algorithm" to choose and understandable - including the cutesy island metaphor from the paper to appear approachable - and the Raft paper opens with a paragraph more or less going "ok we had a bunch of people try to understand Paxos and none of them could figure it out". Anytime I see someone recommend Paxos I silently am judging if they've actually ever read the paper or just parroting advice from when it was the only game in town.
jen20 7 hours ago [-]
Do you ever bother to ask whether they are recommending it for a use case other than a replicated log?
baxter001 11 hours ago [-]
I recall doing a rather large technical case for using raft and a replicated log for water industry back in 2017 it must have been.
That's from knowing nothing about the shape of consensus algorithms to almost getting one adopted.
To me Raft's brilliance is how easy, clear and comprehensible they made thinking about it.
jlundberg 13 hours ago [-]
I highly recommending anyone interested in high availability to read the Raft specification.
dunkelheit 12 hours ago [-]
Kudos to the raft authors for making distributed consensus accessible. Structuring the presentation in terms of RPCs and making the algorithm well-suited for implementing replicated state machines may not sound like a big deal, but those decisions really helped to make it approachable.
In a span of a decade consensus transformed from an esoteric algorithm that you can maaaaybe try implementing if you are a google engineer, to being widely deployed across many storage systems and readily accessible libraries and Raft played a big part in it.
almostgotcaught 7 hours ago [-]
> if you are a google engineer
Do people really have this kind of inferiority complex? What exactly do you think Google engineers are? People with 5 eyes and for hands with 10 fingers each? They read the papers (Paxos or whatever) struggle to understand it, implement beta versions, and iterate just like everyone else.
eatonphil 11 hours ago [-]
Anyone can implement Raft. There are plenty of implementations of them not by Google engineers, including a custom one in the product I work on. And developers in the Software Internals Discord are constantly in there asking questions on the road to implementing Raft or Viewstamped Replication.
trenchpilgrim 11 hours ago [-]
I believe the parent is referring to pre-raft consensus algorithms like Paxos. I recall the explanation of Paxos being a lengthy PDF while the explanation of Raft is a single webpage, mostly visual.
mrkeen 2 hours ago [-]
Other way around.
Step 1 of Raft is for the distributed nodes to come to consensus on a fact - i.e. who the leader is.
ALL of Paxos is the distributed nodes coming to consensus on a fact.
Raft just sounds easier because its descriptions use nice-sounding prose and gloss over the details.
eatonphil 11 hours ago [-]
Could be, it was a little ambiguously worded. That said, single-decree Paxos is much simpler than Raft but I agree The Part-Time Parliament's analogy is a pain to read. But it's better if you just ignore the beginning chunk of the paper and read like the appendix; A1 The Basic Protocol being simpler to understand.
mananaysiempre 10 hours ago [-]
There’s also the side-by-side Paxos/Raft comparison in Howard & Mortier’s “Consensus on consensus”[1] paper, which is not enough to understand either by itself, but a great help if have a longer explanation you’re going through.
So it is a democratic vote and they are all on the same raft, is that the word play they were going for?
nateha 1 hours ago [-]
You take a raft to get off the island of Paxos.
brcmthrowaway 5 hours ago [-]
What is used at Google?
q3k 11 minutes ago [-]
Back in my day it was all Paxos (Chubby, Borgmaster, ...).
jorangreef 51 minutes ago [-]
I heard on good authority that one of the earliest implementations of consensus at Google involved Sanjay Ghemawat tangentially. Sanjay's PhD on Harp, with Barbara Liskov, had also been based on Viewstamped Replication, and so, internally, this became the first flavor at Google. Later, it would come to be referred to externally as Paxos, only because that was more well known at the time.
https://transactional.blog/blog/2024-data-replication-design...
I was like, "wait, that's what raft does, and my game state is already a state machine ... let's do this thing". I then ended up putting my entire game state into raft, and even abused it as a generic pubsub engine.
It was fun, and it worked, and was actually not hard to setup using the Rust implementation. Then when I was done, I realized how pathological it was to put literally all game state and every single event into Raft, so decided to stop indulging myself by having fun and trying to hack Raft into an unintended use case, and just used Redis for game state and pubsub.
I never load tested the Raft implementation, but once I do have some perf testing tools, I'd be interesting to run the Raft code vs. Redis comparison to see how throughput differs. For this use case, at some point Raft should fall over while Redis would be chugging along.
I know what a multiplayer game is, but what's a multiplayer io game?
(not being snarky, i loved your comment)
It’s hinted at in the introduction to the Raft paper, that Raft is "most notably" similar to Viewstamped Replication from Brian Oki, Barbara Liskov and James Cowling at MIT. Reason being that Raft’s primary goal was not so much to reinvent or contribute consensus, so much as to repackage consensus to be "more understandable than Paxos". Nevertheless, it’s not widely known, and probably could be emphasized a bit more, that the protocol is otherwise pretty much ‘88 Oki VSR (same essential protocol, different terms), itself predating Paxos a year.
For example, if you compare '14 Raft (Stanford) with '12 VSR (MIT’s revision to their ‘88 original), the resemblance is striking:
2012: http://pmg.csail.mit.edu/papers/vr-revisited.pdf [1]
2014: https://raft.github.io/raft.pdf
Presentation aside, the only major difference is that Raft’s view change (called leader election in the Raft paper) preserves the flavor of Oki’s ‘88 Viewstamped Replication view change, electing the candidate with the longest log, and missing out on the improved round-robin view change from MIT in ‘12, that brings better stability and availability, with lower latency, and no dueling leaders.
Raft has had a tremendous impact, compared to Paxos, in helping engineers to understand consensus. But once the training wheels are there, it’s important that we also understand and preserve the history of consensus, the people who pioneered these protocols.
[1] It's an accident of history that '12 VSR wasn't promoted as much as Raft would be, two years later. Otherwise, '12 VSR from James Cowling is arguably just as understandable, if not more. For example, because of the improved view change, the paper can begin immediately with normal replication. And there's no discussion, for example, of the need for randomized timeouts, it's elegantly designed away.
'14 Raft missed this upgrade, unfortunately (despite citing the '12 paper), thus preserving Oki's '88 "pick the candidate with longest log".
I find the history of consensus fascinating, and was fortunate to interview both Brian Oki and James Cowling (so many anecdotes): https://www.youtube.com/watch?v=ps106zjmjhw
I think the Raft paper is more approachable for newcomers, but if you are finding Paxos hard to explain and Raft easy to explain, just use the Raft lingo to explain Paxos.
That's from knowing nothing about the shape of consensus algorithms to almost getting one adopted.
To me Raft's brilliance is how easy, clear and comprehensible they made thinking about it.
In a span of a decade consensus transformed from an esoteric algorithm that you can maaaaybe try implementing if you are a google engineer, to being widely deployed across many storage systems and readily accessible libraries and Raft played a big part in it.
Do people really have this kind of inferiority complex? What exactly do you think Google engineers are? People with 5 eyes and for hands with 10 fingers each? They read the papers (Paxos or whatever) struggle to understand it, implement beta versions, and iterate just like everyone else.
Step 1 of Raft is for the distributed nodes to come to consensus on a fact - i.e. who the leader is.
ALL of Paxos is the distributed nodes coming to consensus on a fact.
Raft just sounds easier because its descriptions use nice-sounding prose and gloss over the details.
[1] https://dl.acm.org/doi/10.1145/3380787.3393681
Paxos is used in Spanner.
Raft: Understandable Distributed Consensus (2014) - https://news.ycombinator.com/item?id=41669850 - Sept 2024 (87 comments)
The Raft Consensus Algorithm (2015) - https://news.ycombinator.com/item?id=37369826 - Sept 2023 (76 comments)
Implementing a distributed key-value store on top of implementing Raft in Go - https://news.ycombinator.com/item?id=36070426 - May 2023 (79 comments)
Strong Consistency with Raft and SQLite - https://news.ycombinator.com/item?id=35246228 - March 2023 (42 comments)
Raft Is So Fetch: The Raft Consensus Algorithm Explained Through Mean Girls - https://news.ycombinator.com/item?id=33071069 - Oct 2022 (53 comments)
Raft Consensus Animated (2014) - https://news.ycombinator.com/item?id=32484584 - Aug 2022 (67 comments)
Why use Paxos instead of Raft? - https://news.ycombinator.com/item?id=32467962 - Aug 2022 (45 comments)
In Search of an Understandable Consensus Algorithm (2014) [pdf] - https://news.ycombinator.com/item?id=29837995 - Jan 2022 (12 comments)
Raft Consensus Protocol - https://news.ycombinator.com/item?id=29079079 - Nov 2021 (51 comments)
Paxos vs. Raft: Have we reached consensus on distributed consensus? - https://news.ycombinator.com/item?id=27831576 - July 2021 (48 comments)
In Search of an Understandable Consensus Algorithm (2014) [pdf] - https://news.ycombinator.com/item?id=23113419 - May 2020 (26 comments)
Paxos vs. Raft: Have we reached consensus on distributed consensus? - https://news.ycombinator.com/item?id=22994420 - April 2020 (65 comments)
Raft Is So Fetch: The Raft Consensus Algorithm Explained Through Mean Girls - https://news.ycombinator.com/item?id=22520040 - March 2020 (4 comments)
In Search of an Understandable Consensus Algorithm [pdf] - https://news.ycombinator.com/item?id=14724883 - July 2017 (14 comments)
Raft Consensus Algorithm - https://news.ycombinator.com/item?id=9613493 - May 2015 (24 comments)
The Raft Consensus Algorithm - https://news.ycombinator.com/item?id=8527440 - Oct 2014 (27 comments)
Raft: Understandable Distributed Consensus - https://news.ycombinator.com/item?id=8271957 - Sept 2014 (79 comments)
And probably etcd uses it or similar.