Apache zookeeper 如何处理无序和无等待写入？

如下列文件所述：

顺序一致性-客户端的更新将按发送顺序应用

让我们假设一个客户机在很短的时间内进行了2次更新（update1和update2）（我知道zookeeper擅长于读取控制应用程序）。因此，我的问题是：

是否可能在update1之前收到update2，因此对于zookeeper，update1的戳记晚于update2？由于网络连接的性质，我假设是。如果出现这种情况，则意味着客户端将丢失其update2，并将拥有update1。zookeeper是否可以使用不同的戳记或任何其他数据回显客户端，以让客户端确定在update1之后是否确实收到update2。基本上zookeeper会告诉客户端它从服务器端看到了什么，这会给客户端一些信息，以便在客户端不希望看到的情况下采取行动

如果在接收并确认更新1之后和接收更新2之前出现领导失败怎么办？我假设这样的写入会被保存在磁盘/DB等的某个地方。当新的领导者回来时，它会先赶上吗？也就是说，在向客户确认更新2之前，先进行更新1

奇怪的是，既然zookeeper声称它支持无等待写入，这是否意味着zookeeper内部构建了一个消息队列来保存传入的写入？否则，如果领导者必须确保将更新填充到所有其他追随者，则在复制过程中，客户端实际上被其他追随者阻止。我猜这就是zookeeper不支持重写应用程序的部分原因

---

关于前两个问题，我想您可以在中找到详细信息

来自同一客户机的不同操作无序地到达Zookeeper节点是很正常的。但Zookeeper使用TCP来确保有序地接收顺序网络包

领导必须在提前写日志中写入操作，然后才能确认操作。这些问题将在两个方面产生分歧。我们首先要考虑的是领导者能否在追随者意识到领导失败之前恢复。如果是，则不会发生任何错误，所有失败时间内的操作都将丢失，客户端将重新发送操作。如果没有，那么我们应该考虑领导者是否在提案失败之前提出了建议。如果在提出建议之前失败，那么客户将知道失败。如果它提出了一个建议，那么集群中必须至少有一个节点拥有最新的事务。然后它将成为下一轮的新领导者。当原始领导者从失败中恢复时，它将意识到他不再是领导者（Zookeeper的所有事务都包含一个64位事务id，其中较高的32位代表历元，较低的32位代表提议id）。它将与新的领导者通信，然后得到更新（有时需要先截断其本地事务日志）

我不知道细节，因为我还没有读过ZooKeeper的源代码。但领导者在回应客户之前只需要获得追随者超过一半的认可。Zookeeper同时提供阻塞和非阻塞API，您可以选择自己喜欢的API