ZooKeeper总是CP（就CAP定理而言）是否正确？ 或者是否仍然将其用作服务发现需求的AP？
答案 0 :(得分：8)
Zookeeper不是A，也不能丢弃P.所以它显然叫做CP。就CAP定理而言，“C”实际上意味着线性化。
线性化：如果操作B在操作A成功完成后启动，则操作B必须看到系统处于完成操作A或更新状态时的状态。
但是， Zookeeper具有顺序一致性 - 来自客户端的更新将按照发送顺序应用。
事实上，ZooKeeper在客户端视图中并不是一致的。 http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkGuarantees
ZooKeeper不保证在每个实例中，两个不同的客户端将具有相同的ZooKeeper数据视图。由于网络延迟等因素，一个客户端可能会在另一个客户端收到更改通知之前执行更新。考虑两个客户端A和B的场景。如果客户端A将znode / a的值从0设置为1，然后告诉客户端B读取/ a，则客户端B可以读取旧值0，具体取决于哪个服务器它连接到。如果客户端A和客户端B读取相同的值很重要，则客户端B应该在执行读取之前从ZooKeeper API方法调用sync（）方法。
ZooKeeper提供“顺序一致性”。这比线性化弱，但仍然非常强，比“最终一致性”强得多。 ZooKeeper还提供了sync命令。如果您调用同步命令然后读取，则保证读取至少看到在同步开始之前完成的最后一次写入。
linearizability，写作应该是即时的。不精确的是，一旦写入完成，所有后来的读取（其中“稍后”由挂钟开始时间定义）应该返回该写入的值或稍后写入的值。一旦读取返回特定值，所有后续读取都应返回该值或稍后写入的值。“
在Zookeeper中，他们使用sync（）方法来处理我们需要线性化的东西。
Serializability是对一个或多个对象的事务或一组或多组操作的保证。它保证在多个项目上执行一组事务（通常包含读取和写入操作）等同于事务的某些串行执行（总排序）。
参考：
答案 1 :(得分：2)
不，您无法像在其他系统中那样更改当前版本的ZooKeeper中的一致性保证。
您可以向客户端添加本地缓存，这将使他们在群集关闭时具有只读数据，但在CAP方面仍然不是A，因为它需要可用于更新和读取。< / p>
如果ZK为您的服务发现需求提供过高级别的一致性，您应该尝试研究其他选项，例如：尤里卡，领事或其他。
可能相关的读物：
答案 2 :(得分：1)
一个很好的问题。
就CAP定理而言，“C”实际上意味着线性化：
如果在操作A成功完成后操作B开始，那么 操作B必须看到系统处于与其相同的状态 完成操作A，或更新的状态。
由于在仲裁确认后，ZooKeeper中的写入被认为已完成，因此仍然可能存在旧数据的陈旧节点。因此，严格来说，ZooKeeper默认情况下不是CP系统，即使它提供了相当高的一致性。您可以通过使用sync命令进行读取来确保线性化。
关于网络分区下的可用性，那些不占多数的节点不再处理写请求，因为它们没有仲裁。
另见：