【发布时间】：2017-02-12 07:52:29
【问题描述】：
我浏览了etcd3 的最新版本（2016 年 6 月 30 日发布）的文档，它比etcd2 有很多改进。
其中包括，
- 通过单个 TCP 连接多路复用流式监视
- 增量快照以避免在创建快照时性能下降。
- grpc 调用以提高客户端的性能
- 多路复用流式租赁以减少网络使用。
当谈到写在apache zookeeper 之上的apache curator 时，它的优势在于它是一个可靠、成熟的项目，有许多活跃的客户在生产中使用它。
Zookeeper 每个手表使用单独的 tcp 连接，每个租约使用单独的 tcp 连接。此外，zookeeper 的 watch 服务每个 watch 请求只通知一个事件，如果我们要持续监视特定节点，我们必须发出另一个 watch 请求。由于 etcd3 正在使用多路复用流，因此它不会因过多的 tcp 连接而耗尽网络。
另外，etcd3 和 zookeeper 使用两种不同的算法来达成共识，ZAB 和 raft，其中 raft 不太复杂。
我想实现distributed locks, (use) watches and need to write a mechanism to share commands throughout the cluster using the watch api。此实现将插入到用 java 编写的 ESB。
现在我的问题是，我应该为我的实施选择哪些（curator/etcd3）？为什么？
我希望看到一个好的解释，因为我找不到这两种实现的直接比较。
提前致谢！
【问题讨论】：
-
一个简单的澄清问题是您的客户端将使用哪种语言。我不相信 etcd 或 consul 有一个好的 Java 客户端。相反，我认为 ZooKeeper 没有一个好的 Go 客户端。
-
不，
client或客户的语言实际上不是问题。如果它有一个好的 API，那么编写一个客户端只是时间问题。我关心的是pros和cons每个实现都优于另一个。 -
“如果它有一个好的 API” - 大的“如果”。即使有一个好的 API，通常也有一些习语/食谱等可以使编写成功的应用程序变得困难或容易。想想没有好的驱动程序的数据库。
标签： java apache-zookeeper etcd apache-curator etcd3