Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Related, here is Raft's (another distributed consensus implementation) documentation: https://raft.github.io/. The interactive visualization helps with understanding how it works.


Not to call you out specifically but there's a weird pavlovian response on this site where people have to say the word "raft" when they see the word "paxos". It happens in every comment section without fail. The consensus world moved on from the paxos vs raft battle; the user learning study happened in 2013. Seven years ago! It's time to update our comment sections to reflect that. Here's an excerpt from a 2015 parody blogpost:

What’s etcd?

-It’s an implementation of RAFT.

OK, so what’s Raft?

-It’s like Paxos.

Christ, how deep down this fucking rabbit hole are we going? I just want to launch an app. Sigh. Fuck, OK, deep breaths. Jesus. OK, what’s Paxos?

-Paxos is like this really old distributed consensus protocol from the 70s that no-one understands or uses.

Great, thanks for telling me about it then. And Raft is what?

-Since no-one understands Paxos, this guy Diego…

Oh, you know him?

-No, he works at CoreOS. Anyway, Diego built Raft for his PhD thesis cause Paxos was too hard. Wicked smart dude. And then he wrote etcd as an implementation, and Aphyr said it wasn’t shit.

https://circleci.com/blog/its-the-future/

Anyway Paxos was published in 1998.


I posted the link as another example for understanding a consensus implementation due to its interactive visualization. I was not intending on starting a consensus war, apologies if it came across that way.


In Raft, what would happen in case of following:

1. The master has sent request to followers to update their state

2. Half of the followers successfully update their state and other half fail for some reason

3. Now, master crashes and new master gets picked from the other half which never updated their states

Wouldn’t we have inconsistent state now?


A commit has to be replicated to majority of the cluster, and a leader is elected by approval of majority of the cluster.

More than that each of the nodes approving the commit would reject a candidate who has log inconsistent with their history. Therefore a node with inconsistent log could not be elected as a leader.

In raft paper it's shown in 5.4.3 (safety argument).


If half the nodes fail the cluster has failed. Raft and Paxos need at least a majority of nodes. It's actually not beneficial (except for load-balancing) to run an even number of nodes.


> 3. Now, master crashes and new master gets picked from the other half which never updated their states

> Wouldn’t we have inconsistent state now?

No. The half that received the event will all have a higher event count (what raft refers to as a "term"), so one of them will become the master because they're not voting for someone who knows less than they do (and neither is anyone else!)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: