Zookeeper 和 ETCD的对比

这篇文章分析的比较好了 Apache ZooKeeper vs. etcd3,我把主要的对比翻译一下。

Zookeeper

优点

• 非阻塞的全量快照（用来实现最终一致性）
• 有效的内存管理
• 可靠（已经开发了很长时间）
• API 简单
• 自动重试的 ZooKeeper 连接管理。
• 完整的，测试充分的实现。
• 通过watch实现事件通知。
• 当网络分割时，小的分区和大的分区都会开始Leader选举。因此，小的分区因为服务器少会停止。

缺点

• 因为 ZooKeeper 是用java写的，有Java语言的固有缺陷（如垃圾回收导致的停顿）。
• 当创建快照时（数据被写到磁盘），ZooKeeper 的读写操作会暂时停止。这仅当 启用快照时发生，如果不启用快照，ZooKeeper 是一个分布式的内存存储服务。
• ZooKeeper 为每一个 watch 请求创建一个新的 socket 连接。会导致在生产环境中很多 socket 连接。

ETCD

优点

• 增量快照避免创建快照时的停顿问题，这是 ZooKeeper 的一个问题。
• 没有垃圾回收导致的停顿问题，因为使用的是堆外存储。
• 重新设计了Watchers（监听），不再为每个监听创建一个 socket，多个事件复用一个连接。
• ZooKeeper 监听事件触发时，需要再次监听对象。 etcd 可以持续监听一个对象。
• etcd3 保持一个滑动窗口会保持旧的事件，断开当前连接不会导致事件丢失。

缺点

• 如果超时，或者网络扰动，客户端不能确定请求的结果。如果发生Leader 选举时，etcd 会中断所有操作。 当因上述原因操作中断时，etcd不会发送给客户端发送终止的响应。
• 当网络分裂时，如果较小的部分是 Leader，会继续提供序列化的读请求服务。
• 不支持临时结点。Ephemeral nodes?。 只能是加Lease, Lease需要不断更新，否则用此Lease创建的key会自动清理掉。 浅析jetcd中KeepAlive实现及使用
• 结点没有层次的概念，每个key都是独一无二的。/path, /path/, /path/subpath1, /path/subpath2没有任何关系。etcd 有按前缀获取List的方法。
• Java 测试用例不好写，需要单独先启动一个etcd，测试完之后再关掉etcd。jetcd用本地的docker环境启动指定几个节点的etcd 容器。