1. etcd与zookeeper比较

  1. CAP原则 zookeeper和etcd都是顺序一致性的(满足CAP的CP),意味着无论你访问任意节点,都将获得最终一致的数据视图。这里最终一致比较重要,因为zookeeper使用的paxos和etcd使用的raft都是quorum机制(大多数同意原则),所以部分节点可能因为任何原因延迟收到更新,但数据将最终一致,高度可靠。

  2. 逻辑结构 zookeeper从逻辑上来看是一种目录结构,而etcd从逻辑上来看就是一个k-v结构。

但etcd的key可以是任意字符串同时在存储上实现了key有序排列。

所以仍旧可以模拟出父子目录关系,例如:key=/a/b/c、/a/b、/a

结论:etcd本质上是一个有序的k-v存储。

  1. 临时节点 在实现服务发现时,我们一般都会用到zookeeper的临时节点。当客户端掉线一段时间,对应的zookeeper session会过期,那么对应的临时节点就会被自动删除。

在etcd中对应的是lease租约机制,通过该机制实现了key的自动删除。

可以在set key的同时携带lease ID,当lease过期后所有关联的key都将被自动删除。

  1. 事件模型 在我们用zookeeper实现服务发现时,我们一般会getChildrenAndWatch来获取一个目录下的所有在线节点,这个API会先获取当前的孩子列表并同时原子注册了一个观察器。

每当zookeeper发现孩子有变动的时候,就会发送一个通知事件给客户端(同时关闭观察器),此时我们会再次调用getChildrenAndWatch再次获取最新的孩子列表并重新注册观察器。

简单的来说,zookeeper提供了一个原子API,它先获取当前状态,同时注册一个观察器,当后续变化发生时会发送一次通知到客户端:获取并观察->收到变化事件->获取并观察->收到变化事件->….,如此往复。

zookeeper的事件模型非常可靠,不会出现发生了更新而客户端不知道的情况,但是特点也很明显:

事件不包含数据,仅仅是通知变化。 多次连续的更新,通知会合并成一个;即,客户端收到通知再次拉取数据,会跳过中间的多个版本,只拿到最新数据。 这些特点并不是缺点,因为一般应用只关注最新状态,并不关注中间的连续变化。

相反etcd的事件是包含数据的,并且通常情况下连续的更新不会被合并通知,而是逐条通知到客户端。

Copyright © 温玉 2021 | 浙ICP备2020032454号 all right reserved,powered by Gitbook该文件修订时间: 2023-10-26 17:23:11

results matching ""

    No results matching ""