ZooKeeper在CAP理论方面是否始终保持一致？

Question

ZooKeeper在CAP理论方面是否始终保持一致？

apache-zookeeperservice-discoveryeventual-consistencycap-theorem

23

ZooKeeper是否总是满足CAP理论中的CP呢？还是有办法将其用作面向服务发现的AP呢？

- Artem

3个回答

6

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

你可以为客户端添加本地缓存，如果集群崩溃，它们将具有只读数据，但就CAP而言，这仍然不是A，因为它需要对更新和读取都可用。

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

可能相关的阅读材料：

- igorbel

4

一个很好的问题。

在CAP定理中，“C”实际上意味着线性一致性：

如果操作B在操作A成功完成后开始，则操作B必须看到系统处于与操作A完成时相同的状态或更新的状态。

由于ZooKeeper中的写入在仲裁确认后被视为已完成，因此仍可能存在具有旧数据的陈旧节点。因此，严格来说，默认情况下ZooKeeper不是CP系统，尽管它提供了相当高的一致性水平。您可以通过在读取之前使用sync命令来确保线性一致性。

关于网络分区下的可用性，那些不在多数派中的节点将无法再处理写请求，因为它们没有仲裁。

另请参见：

- Miljen Mikic

1

非常好的参考资料！:) - undefined

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- prime · Accepted Answer

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还提供了一个同步命令。如果您调用同步命令，然后进行读取操作，读取将保证至少看到在同步开始之前完成的最后一次写入。

在线性一致性中，写操作应该看起来是瞬间完成的。简单地说，一旦写操作完成，所有之后的读操作（其中“之后”由墙上时钟开始时间定义）应该返回该写操作的值或更晚的写操作的值。一旦读操作返回了特定的值，所有之后的读操作都应该返回该值或更晚的写操作的值。

在Zookeeper中，它们有一个sync()方法，在需要类似于线性一致性的场景下使用。

串行化是关于事务或一组对一个或多个对象的操作的保证。它保证在多个项目上执行一组事务（通常包含读取和写入操作）等价于一些事务的串行执行（完全排序）。