zk的一致性保证官翻

Consistency Guarantees

ZooKeeper is a high performance, scalable service. Both reads and write operations are designed to be fast, though reads are faster than writes. The reason for this is that in the case of reads, ZooKeeper can serve older data, which in turn is due to ZooKeeper's consistency guarantees:
zk是一个高性能，可伸缩的组件。读和写都非常快。尽管读比写更快。为什么会有这样？因为zk读取数据的时候，返回当前node 中zxid最大的数据，zxid最大有可能是已经同步过的最新数据，也有可能是上一个版本的老数据，这就是一致性的保证。换句话说，你读取同一个节点NodeA的数据，肯定是读取的当前节点NodeA最新的数据，但不一定是全局所有节点最新的数据。

• Sequential Consistency : Updates from a client will be applied in the order that they were sent.
  顺序一致性，客户端先发送更新请求m，然后发送更新请求n，服务端保证m肯定在n之前更新

• Atomicity : Updates either succeed or fail -- there are no partial results.
  更新原子性，要么成功，要么失败没得中间状态

• Single System Image : A client will see the same view of the service regardless of the server that it connects to. i.e., a client will never see an older view of the system even if the client fails over to a different server with the same session.
  单一视图：无论客户端连接到哪个服务器，客户端都将看到该服务的相同视图。 即：即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧视图
  最终一致性，客户端读取的时候可能读到不是最新的数据，但是最终一定会读到最新的数据

• Reliability : Once an update has been applied, it will persist from that time forward until a client overwrites the update. This guarantee has two corollaries:
  可靠性：一旦一个更新操作提交成功，从那时起它将一直持续到客户端覆盖更新为止

  1. If a client gets a successful return code, the update will have been applied. On some failures (communication errors, timeouts, etc) the client will not know if the update has applied or not. We take steps to minimize the failures, but the guarantee is only present with successful return codes. (This is called the monotonicity condition in Paxos.)这在Paxos中称为单调性条件
  2. Any updates that are seen by the client, through a read request or successful update, will never be rolled back when recovering from server failures.

• Timeliness : The clients view of the system is guaranteed to be up-to-date within a certain time bound (on the order of tens of seconds). Either system changes will be seen by a client within this bound, or the client will detect a service outage.
  及时性：

Using these consistency guarantees it is easy to build higher level functions such as leader election, barriers, queues, and read/write revocable locks solely at the ZooKeeper client (no additions needed to ZooKeeper). See Recipes and Solutions for more details.

Note

Sometimes developers mistakenly assume one other guarantee that ZooKeeper does not in fact make. This is: * Simultaneously Consistent Cross-Client Views* : ZooKeeper does not guarantee that at every instance in time, two different clients will have identical views of ZooKeeper data.
两个不同的客户端对ZooKeeper数据具有相同的视图，也就是两个客户端连接的不同节点，有的时候它们的数据就是不一致的。

Due to factors like network delays, one client may perform an update before another client gets notified of the change.
有可能是网络延迟，一个客户端可以在另一个客户端收到更改通知之前执行更新

Consider the scenario of two clients, A and B. If client A sets the value of a znode /a from 0 to 1, then tells client B to read /a, client B may read the old value of 0, depending on which server it is connected to. If it is important that Client A and Client B read the same value, Client B should call the sync() method from the ZooKeeper API method before it performs its read.
假设一个例子：有客户端A、客户端B ；现在客户端A将节点 /a 的值从0更新为1，客户端B马上读取节点/a 此时客户端B读取到的值可能是0，这取决于客户端B连接的zk节点数据是否同步到最新的版本了。如果你一定要保证此时客户端B读取的数据和客户端A读取的一致，那么你必须自己先手动调用 sync() 方法做同步，然后再读取。zk服务端不保证每个节点都实时同步完成。

So, ZooKeeper by itself doesn't guarantee that changes occur synchronously across all servers, but ZooKeeper primitives can be used to construct higher level functions that provide useful client synchronization. (For more information, see the ZooKeeper Recipes.