Zookeeper Watches文档指出：
"客户端将看到它正在监视的 znode 的监视事件，然后再看到与该 znode 对应的新数据。"此外，"由于手表是一次性触发器，并且在获取事件和发送新请求以获取手表之间存在延迟，因此您无法可靠地看到 ZooKeeper 中节点发生的每一个更改。
关键是，不能保证您会收到手表通知。
这很重要，因为在像Clojure的Avout这样的系统中，你试图使用Zookeeper通过网络模仿Clojure的软件事务内存。这依赖于每个更改都有一个监视通知。
现在我试图弄清楚这是一个编码缺陷，还是一个基本的计算机科学问题（即CAP定理）。
我的问题是：Zookeeper Watches系统是否有错误，或者这是CAP定理的限制？
这似乎是 ZooKeeper 实现手表方式的限制，而不是 CAP 定理的限制。有一个开放的功能请求将连续监视添加到ZooKeeper：https://issues.apache.org/jira/browse/ZOOKEEPER-1416。
etcd 有一个使用长轮询的监视功能。这里需要考虑的限制是，在接收第一个长轮询结果和重新轮询之间可能会发生多个事件。这大致类似于ZooKeeper的问题。但是他们有一个解决方案：
但是，监视命令可以执行更多操作。使用索引[传递我们看到的最后一个索引]，我们可以监视过去发生的命令。这对于确保您不会错过监视命令之间的事件非常有用。
curl -L 'http://127.0.0.1:4001/v2/keys/foo?wait=true&waitIndex=7'