Apache ZooKeeper 是一种针对小对象的高可用数据存储。 ZooKeeper 集群由一些节点组成，这些节点都将整个数据集保存在内存中。该数据集被称为“始终一致”，因此每个节点每次都有相同的数据。
根据文档和博客文章 http://www.cloudera.com/blog/2009/12/observers-making-zookeeper-scale-even-further/，集群中的每个节点都可以应答读取并接受写入。
- 读取始终由节点在本地应答，因此不涉及与集群的通信。
- 写入被转发到指定的“领导者”节点，该节点将写入请求转发到所有节点并等待它们的回复。如果至少一半节点应答，则认为写入成功。
问题：为什么领导者需要等待一半节点回复就足够了？如果有人连接到未收到更新的节点之一，他会得到过时的结果（仅本地读取本地值）。
为了实现高读可用性，Zookeeper保证复制的弱一致性：读总是可以由客户端节点应答，并且返回的答案可能是过时的值（即使已经通过领导者提交了新版本） ）。
然后，用户有责任决定读取的答案是否“可陈旧”，因为并非所有应用程序都需要最新信息。因此提供以下选择：
1) 如果您的应用程序不需要读取最新值，您可以通过直接向客户端请求数据来获得高读取可用性。
2) 如果您的应用程序需要读取最新值，则应在读取请求之前使用“sync”API 将客户端版本与领导者同步。
所以总而言之，Zookeeper提供了可定制的一致性保证，用户可以决定可用性和一致性之间的平衡。
如果你想了解更多Zookeeper的内部原理，我推荐这篇论文：ZooKeeper：互联网规模系统的无等待协调 http://www.usenix.org/events/usenix10/tech/full_papers/Hunt.pdf。上述策略在 4.4 节中描述。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
