在应⽤程序中，需要知道ZooKeeper集合的状态，这种情况并不少见。例如，在前面的例⼦中，备份主节点需要知道主要主节点已经崩溃，从节点需要知道任务分配给了⾃⼰，甚⾄ZooKeeper的客户端会定时轮询ZooKeeper集合，检查系统状态是否发⽣了变化。然⽽轮询⽅式并⾮⾼效的⽅式，尤其是在期望的变化发⽣频率很低时。
举例说明，在主要主节点崩溃时，备份主节点需要知道这⼀情况，以便它们可以进⾏故障处理。为了减少主节点崩溃后的恢复时间，我们需要频繁轮询，如每50毫秒，只是为了⽤⽰例说明积极轮询的情况。在这种情况下，每个备份主节点每秒会产⽣20个请求，如果有多个备份主节点，备份主节点的数量乘上这个频率，就得到了为得到主要主节点状态⽽轮询ZooKeeper所消耗的全部请求量，即使像ZooKeeper这样的系统处理这个数量请求也⾮常简单，但主要主节点崩溃的情况很少发⽣，因此这些请求其实是多余的。假设我们通过增加主节点状态查询的轮询周期来减少对ZooKeeper的查询数量，如1秒，周期时间的增加则会导致主节点崩溃时恢复时间的增加。
我们完全可以通过ZooKeeper通知客户端感兴趣的具体事件来避免轮询的调优和轮询流量。ZooKeeper提供了处理变化的重要机制——监视点（watch）。通过监视点，客户端可以对指定的znode节点注册⼀个通知请求，在发⽣变化时就会收到⼀个单次的通知。例如，我们的主要主节点创建了⼀个临时性的znode节点来标识主节点锁，⽽备份主节点注册⼀个监视点来监视这个主节点锁是否存在，如果主节点崩溃，主节点锁⾃动被删除，并通知所有备份主节点。⼀旦备份主节点收到通知，它们就可以开始进⾏主节点选举，如获得管理权限中所述，通过尝试创建⼀个临时的znode节点来标识主节点锁。
监视点和通知形成了⼀个通⽤机制，使客户端可以观察变化情况，⽽不⽤不断地轮询ZooKeeper。我们已经通过主节点的例⼦进⾏了说明，但该通⽤机制还适⽤于很多情况。
网友评论