locker
locker copied to clipboard
How this compares to Raft ?
I wonder how this project compares with Raft consensus. It looks like they have a lot in common, doesn't it?
Yes, many of the use cases for locker could also be solved with a consensus system based on Raft, like Consul or etcd.
Architecturally, they are very different through. Locker uses two-phase commit, with a majority of masters required to participate, while Raft elects a leader and sends writes to the leader. Locker requires two round trips, while Raft requires only one. Raft also deals with changes in the cluster configuration (adding and removing nodes), while locker leaves this up to the administrator.
Locker is designed for applications running in an Erlang cluster, where you want strong consistency for coordination. If you want to coordinate among services (maybe written in different languages), Consul or etcd would be a better fit.
Hi, @knutin how this compares to paxos??
Example: cluster of 3 machines, quorum is 2.
What happens, when after locking one of the quorum participant dies, without information, if he has saved information or not? The writes propagates only to 1 node. Than you have 2 nodes with different state. How it will be decided, which values on node 1 or 3 will be replicated?
Red presentation and README, this answers my questions, thanks! :+1: