etcd与zookeeper
从以下几个点来说说etcd与zookeeper：
- 关于cap
- 逻辑结构
- 临时节点
- 事件模型
- 分布式一致性协议
关于cap
对用户而言，二者都满足强一致性，即满足cap的（cp），无论client访问的是哪个节点，获得的数据视图是最终一致的。但是对于集群，是最终一致性的，因为它们都是满足Quorum机制（大多数同意原则），所以几点的数据可能会有延迟同步全部节点，但是最终总是趋于一致性的。
逻辑结构
zk是文件目录结构，但etcd是k-v结构，但是因为是字符串，所以可以模拟出文件目录结构。如：key=/app1/server/user，这样就代表了一个目录路径。同时由于etcd在存储上key实现使有序排列的，如/app1/server/user1，/app1/server/user1，/app1/server/user1，因此，也可以表达出父子关系。通过定位到key=/app1/server/并依次顺序向后扫描，就会得到/app1/server/user1，/app1/server/user1，/app1/server/user1这三个child，从而一样可以实现父子目录关系。
zk逻辑结构
etcd逻辑结构
临时节点
zk的临时节点代表了一个会话session的连接和中断，可以通过临时节点来实现服务注册和发现，是通过这个来实现对于临时节点的增加和删除。
etcd没有临时节点的概念，是通过lease租约机制。即对于一个key，设定一个lease时间，在这个时间内续期key，那么key就会一直存在，若超出租约期限没有续期，key就会被删除（和心跳机制一样），可以通过这样的机制来实现服务注册发现。
事件模型
zk提供了一个原子API（getChildrenAndWatch）来获取当前状态，同时注册一个观察器，当后续变化发生时会发送一次通知到客户端：获取并观察->收到变化事件->获取并观察->收到变化事件->……，如此往复
zk事件模型特点：
- 事件不包含数据，仅仅是通知变化
- 多次连续的更新，通知会合并成一个
etcd通过newWatcher得到一个watch chan，通过这个watch chan来监听对应的key，凡事key有变化（包括变化和数据），会通过chan来实现通知。一个租约可以关联多个key，租约失效，所有key都会被删除（这也是服务发现的实现要点）。所以事件模型是new watcher->get watch chan->for watch key->get change-> data<-watch chan
分布式一致性协议
zk是zab协议，etcd是raft协议。都是经得起考验，能够运用在生产环境的，但是在raft协议以易理解著称。对于raft的分析后面单独文章分析吧。
分布式一致性协议是分布式协调中间件的最关键点，因为其他的第三方组件一般是借助非自身的中间件来实现分布式一致性，比如选主，分布式锁等场景。
