ZooKeeper类协调服务的功能组合与真实用途边界

ZooKeeper/etcd这类”协调与配置服务”表面上像键值数据库，实则专为分布式协调设计：数据量小、能装进内存，通过容错的全序广播复制到所有节点，模仿Google Chubby锁服务组合了四种能力——线性一致的原子操作（CAS，用于实现分布式锁，通常以带超时的租约形式存在）、操作的全序排序（每个操作有单调递增的zxid/cversion，可直接充当[[防护令牌用递增编号让资源方拒绝过期天选者的写入]]需要的令牌）、失效检测（心跳会话超时后临时节点自动消失）、变更通知（客户端订阅而非轮询）。这四项里只有线性一致的原子操作真正需要共识，但正是这个组合让它在两类场景里格外有用：把工作/分区分配给节点（利用原子操作、临时节点和通知实现自动化故障恢复，比自己从零实现共识算法靠谱得多）；辅助领导者选举后的服务发现（服务发现本身其实不需要共识，DNS的最终一致缓存已经够用，但领导者选举需要共识，共识系统的决策结果可以顺带用于告知其他服务谁是领导）。ZooKeeper不适合当通用数据库用，它管理的数据变化通常以分钟或小时为量级，不是每秒可能变化数千次的应用运行时状态。