Quick notes about implementation difference between ZK and ETCD not Paxos vs Raft
- Industry battle tested, it is the most widely used concensus algorithm implementation
- Ephemeral nodes, think global lock.
- Stateful connection to ZK quorum (implies more tight and strong concensus)
- Thick client, a system has to implement ZK client to use it. (more code to main tain and have to worry about each language specific impl.)
- no rest API for control. (although I believe this is in works but can't find the link)
- It's fast despite using http
- Exposed REST API control. No client implementations needed
- It's simpler. leader election is enforced not implied.
- It's still yet to be matured, especially considering concensus algorithm have many surprising edge cases.
- no ephemeral nodes. (etcd have something similar coming in v3 api)
####sources:
- paxos white paper - http://www.cnds.jhu.edu/pub/papers/psb_ladis_08.pdf
- RAFT white paper - http://ramcloud.stanford.edu/raft.pdf
- Camille's video on consensus system - http://www.ustream.tv/recorded/61483409
- Aphyr's etcd blog post - https://aphyr.com/posts/316-jepsen-etcd-and-consul (<------ I think this is a must read as it actually exposed a bug in etcd that compromises linearizability of the system in case of partition during testing)