[atombender]

Apples all the way. Etcd is pretty much a clone of ZooKeeper in Go; they both support hiearchical keys, atomic autoincrement, watches, though Etcd uses the Raft consensus algorithm, whereas ZooKeeper uses its own homegrown algorithm, and there are other minor differences. Both are intended for configuration management and coordination. (Of course, both are ultimately clones of Google's internal tool, Chubby.)

[embiggen]

I agree that they are similar in some ways, but under the covers they are fundamentally different beasts in almost all ways!!!

Etcd uses Raft and ZooKeeper uses it's own protocol called Zab [0]. Zab shares some characteristics with Paxos but certainly IS NOT Paxos.

[0] https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs...

[lobster_johnson]

As I understand it, both Paxos and Zab will result in similar performance characteristics, since writes need, by design, to be coordinated with peers and serialized in a strict manner. In this sense, Etcd and ZK are very much alike, irrespective of how they are implemented internally. I wouldn't be surprised if Etcd was found to be faster and more scalable than ZK, however.

[ideal0227]

It really depends on how you view the problem. Yes, the latency of agreeing a proposal is similar, which is limited by physical (network latency + disk io). However, there are ways to put more stuff into one proposal (batching) and submitting proposals continuously (pipelining). These optimizations highly depend on the implementations.

[jonaf]

I believe ZK implements Pacis. Maybe someone not on mobile can correct me / provide reference.

[Randgalt]

ZK is zab - similar to Paxos but not Paxos