Apache zookeeper ZooKeeper在CAP定理方面总是一致的吗？

ZooKeeper总是CP（根据CAP定理）对吗？

---

或者，是否仍可以将其用作服务发现需要的AP？

否，您不能像在其他一些系统中一样更改ZooKeeper当前版本中的一致性保证

您可以向客户端添加一个本地缓存，这将使它们在集群宕机时具有只读数据，但就CAP而言，这仍然不是一个可用的缓存，因为它需要可用于更新和读取

如果ZK为您的服务发现需求提供了太强的一致性级别，您应该尝试研究其他选项，例如Eureka、Concur或etcd

可能相关内容如下：

这是一个很好的问题
根据CAP定理，“C”实际上意味着线性化能力：
如果操作B在操作A成功完成后启动，则 操作B必须看到系统处于与打开时相同的状态 操作A或更新状态的完成
由于写入ZooKeeper在仲裁确认后被视为已完成，因此仍然可能存在具有旧数据的过时节点。因此，严格来说，ZooKeeper默认不是CP系统，即使它提供了相当高的一致性水平。通过在读取之前使用

sync

命令，可以确保线性化
关于网络分区下的可用性，那些不是多数的节点无法再处理写请求，因为它们没有仲裁
另见：
---

动物园管理员不是一个管理员，而且不能删除p。因此它显然被称为CP。根据CAP定理，“C”实际上意味着可线性化
线性化能力：如果操作B是在操作A成功完成后开始的，则操作B必须看到系统处于与操作A完成时相同的状态或更新的状态
但是,， Zookeeper具有顺序一致性-客户端的更新将按发送顺序应用
事实上，ZooKeeper在客户端视图中并不同时保持一致。
ZooKeeper不保证在任何时候，两个不同的客户端都会有ZooKeeper数据的相同视图。由于网络延迟等因素，一个客户端可能会在另一个客户端收到更改通知之前执行更新。考虑两个客户端A和B的场景。如果客户端A从0到1设置ZNoD/A的值，那么告诉客户端B读/ A，客户端B可以读取0的旧值，这取决于它连接到哪个服务器。如果客户端A和客户端B读取相同的值很重要，那么客户端B应该在执行读取之前从ZooKeeper API方法调用sync（）方法
ZooKeeper提供“顺序一致性”。这比线性化能力弱，但仍然非常强，比“最终一致性”强得多。ZooKeeper还提供了一个同步命令。如果先调用sync命令，然后再调用read，则保证读取至少会看到在同步开始之前完成的最后一次写入

线性化能力

，写入应该是瞬时的。不准确地说，一旦写入完成，所有后续读取（其中“later”由挂钟开始时间定义）都应返回该写入的值或后续写入的值。读取返回特定值后，所有后续读取都应返回该值或后续写入的值。”
在Zookeeper中，当我们需要线性化能力时，他们可以使用sync（）方法。

Serializability

是对一个或多个对象上的事务或一个或多个操作组的保证。它保证对多个项目执行一组事务（通常包含读写操作）相当于事务的某些串行执行（总顺序）
参考：