4 ms·
It's been a few years since I've checked in with distributed lock services. Why would someone adopt ZooKeeper after etcd gained maturity? I recall seeing benchm
by jzelinskie 3y ago
It's been a few years since I've checked in with distributed lock services. Why would someone adopt ZooKeeper after etcd gained maturity? I recall seeing benchmarks more than 5 years ago where a naive proxy like zetcd[0] out-performs ZooKeeper itself in many ways and offers more consistent latencies. etcd has gotten lots of battle-testing being Kubernetes' datastore, but I can also see how that has shaped its design in a way that might not fit other projects.
I think there are plenty of other projects (e.g. FoundationDB, Kafka) that also replaced their usage of ZooKeeper as their systems matured. I guess I'm confused why anyone has been picking up new installations of ZooKeeper.
[0]: https://github.com/etcd-io/zetcd https://github.com/etcd-io/zetcd
- zX41ZdbW 3y agoThere is no specific reason to start with ZooKeeper, nor with ClickHouse Keeper, if you want to use another distributed consensus system. But: every such system is slightly different in the data model and the set of available primitives. It's very hard to build a distributed system correctly, even relying on ZooKeeper/Etcd/FoundationDB. For example, when I hear "distributed lock," I know that there is 90% chance there is a bug (distributed lock can be safely used if every transaction made under a lock also atomically tests that the lock still holds). So, if there is an existing system heavily relying on one distributed consensus implementation, it's very hard to switch to another. The main value of ClickHouse Keeper is its compatibility with ZooKeeper - it uses the same data model and wire protocol.
- endisneigh 3y agoFoundationdb doesn’t use locks, due to that it’s relatively easy to build distributed systems on top, but the trade off are 5sec transaction limits.
- klysm 3y agoThe term “distributed lock” is a bit of a mental red flag to me.