如Guarantees中所述：
顺序一致性 - 来自客户端的更新将按发送顺序应用。
假设客户端在很短的时间窗口内进行了2次更新（update1和update2）（我知道zookeeper擅长读取控制应用程序）。所以我的问题是：
在update1之前是否收到了可能的update2，因此对于zookeeper update1的后续标记比update2的标记更晚？由于网络连接性质，我假设是。如果这种情况意味着客户端将丢失其update2并将具有update1。无论如何，zookeeper可以使用不同的标记或其他任何数据来确认客户端，以便客户端确定update1之后是否真正收到update2。基本上，zookeeper会告诉它从服务器端到客户端的内容，如果不是客户想要的话，它会为客户提供一些信息。
如果在收到并确认update1之后和接收update2之前有领导失败怎么办？我假设这样的写入是在磁盘/数据库等的某个地方持续存在。当新的领导者回来时，它会首先赶上，意味着行为update1，然后再确认update2回到客户端吗？
好奇，因为zookeeper声称它支持无等待写入，这是否意味着在zookeeper中内置了一个消息队列来保存传入的写入？否则，如果领导者必须确保将更新填充到所有其他关注者，则在此复制过程中实际上会阻止客户端。我猜这是动物园管理员不支持重写申请的部分原因。
答案 0 :(得分：1)
对于前两个问题，我认为您可以在Zookeeper's paper中找到详细信息。
来自同一客户端的不同操作无法到达Zookeeper节点是很正常的。但Zookeeper使用TCP来确保顺序网络包将按顺序接收。
领导者必须先在Write-Ahead-Log中写入操作才能确认操作。问题将在两个方面发生分歧。我们应该考虑的第一种情况是领导者能否在追随者意识到领导者失败之前恢复。如果是，则不会发生任何不良情况，所有失败时间的操作都将丢失，客户端将重新发送操作。如果没有，那么我们应该考虑领导者是否在提案失败前提出了提案。如果在提出提案之前失败，那么客户将知道失败。如果提出了提案，则群集中必须至少有一个节点已获得最新的事务。然后它将成为下一轮的新领袖。当原始Leader从失败中恢复时，它将意识到他不再是领导者（Zookeeper的所有事务都包含64位事务id，其中较高的32位表示纪元，而较低的32位表示投标id）。它将与新的Leader进行通信，然后进行更新（有时它需要先截断它的本地事务日志）。
我不知道细节，因为我还没有阅读过ZooKeeper的源代码。但在领导者回应客户之前，领导者只需要来自粉丝的一半以上的承认。 Zookeeper提供阻止和非阻塞API，您可以选择自己喜欢的内容。