ZK和ETCD的产品对比和差异
- [1. 底层实现](#1. 底层实现)
-
- [1.1 高可用机制](#1.1 高可用机制)
- [1.2 数据结构](#1.2 数据结构)
- [2. 客户端视角](#2. 客户端视角)
-
- [2.1 临时数据](#2.1 临时数据)
- [2.2 监听机制](#2.2 监听机制)
探讨zk和etcd的底层实现以及客户端使用上的差异。
更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考
1. 底层实现
1.1 高可用机制
- 相同点：满足quorum机制(大多数同意原则)，数据高度可靠，数据最终一致。
- 不同点：zk基于ZAB协议（基于paxos协议），etcd基于raft协议
1.2 数据结构
- zookeeper: 目录结构
- etcd: k-v结构
但etcd的key可以是任意字符串同时在存储上实现了key有序排列，所以仍旧可以模拟出父子目录关系，例如：key=/a/b/c、/a/b、/a
2. 客户端视角
2.1 临时数据
- 相同点：zk、etcd都支持临时数据过期删除机制
- 不同点：
zookeeper通过session机制实现，当客户端掉线一段时间，对应的zookeeper session会过期，那么对应的临时节点就会被自动删除。
etcd中对应的是lease租约机制，通过该机制实现了key的自动删除，可以在set key的同时携带lease ID，当lease过期后所有关联的key都将被自动删除。
2.2 监听机制
- 相同点：zk、etcd都支持数据变动时，通知客户端
- 不同点：
zookeeper的事件模型非常可靠，不会出现发生了更新而客户端不知道的情况，但是特点也很明显：事件不包含数据，仅仅是通知变化。 多次连续的更新，通知会合并成一个；即，客户端收到通知再次拉取数据，会跳过中间的多个版本，只拿到最新数据。 这些特点并不是缺点，因为一般应用只关注最新状态，并不关注中间的连续变化。
etcd的事件是包含数据的，并且通常情况下连续的更新不会被合并通知，而是逐条通知到客户端。