怎样理解 ZooKeeper 一致性保证中的 Single System Image?( 二 )


但是根据《ZooKeeper Distributed process coordination》Chapter 6 The sync Call
There is a caveat to the use of sync, which is fairly technical and deeply entwined with ZooKeeper internals. (Feel free to skip it.) Because ZooKeeper is supposed to serve reads fast and scale for read-dominated workloads, the implementation of sync has been simplified and it doesn\u0026#39;t really traverse the execution pipeline as a regular update operation, like create, setData, or delete. It simply reaches the leader, and the leader queues a response back to the follower that sent it. There is a small chance that the leader thinks that it is the leader l, but doesn\u0026#39;t have support from a quorum any longer because the quorum now supports a different leader, l? . In this case, the leader l might not have all updates that have been processed, and the sync call might not be able to honor its guarantee.The ZooKeeper implementation deals with this issue by making it unlikely that a quorum of followers will abandon a leader without the leader noticing. It does so by having the leader time out for any given follower based on the tickTime, while a follower decides that a leader is gone by receiving a socket exception, which occurs when the TCP connection between them drops. The leader times out a follower much sooner than a TCP connection expiration. However, the corner case for an error is there, even though it has never been observed to our knowledge.There have been discussions on the mailing list about changing the server handling of sync to traverse the pipeline and eliminate this corner case altogether. Currently, the ZooKeeper implementation relies on reasonable timing assumptions, and consequently no problem is expected.现在有没有改进不太清楚,个人觉得这个可能性的存在还是比较坑的,尤其在使用sync是为了保证正确性的时候。

■网友
文档写得有问题。。。
https://github.com/apache/zookeeper/pull/931


推荐阅读