38、分布式系统中的成员与协调服务

分布式系统中的成员与协调服务

在分布式系统的领域中，像 ZooKeeper 或 etcd 这样的项目常常被描述为“分布式键值存储”或“协调与配置服务”。它们的 API 与数据库颇为相似，能够对给定键进行读写操作，还能遍历键。然而，既然它们本质上类似数据库，为何还要费力去实现共识算法呢？它们与其他类型的数据库又有何不同？

1. ZooKeeper 的使用场景与特点

作为应用开发者，通常很少会直接使用 ZooKeeper，因为它并不适合作为通用数据库。更多时候，是通过其他项目间接依赖它，例如 HBase、Hadoop YARN、OpenStack Nova 和 Kafka 等都依赖 ZooKeeper 在后台运行。

ZooKeeper 和 etcd 旨在存储少量能够完全存入内存的数据（尽管为保证持久性仍会写入磁盘），所以不会将应用的所有数据都存于此。这些少量数据会使用容错的全序广播算法在所有节点间复制，全序广播对于数据库复制至关重要，若每条消息代表对数据库的写入，按相同顺序应用这些写入就能使副本保持一致。

ZooKeeper 借鉴了 Google 的 Chubby 锁服务，不仅实现了全序广播（即达成共识），还具备一系列在构建分布式系统时特别有用的特性：
- 线性化原子操作 ：利用原子比较并设置操作可实现锁。若多个节点同时尝试执行相同操作，只有一个会成功。共识协议确保即使节点故障或网络中断，操作依然是原子且线性化的。分布式锁通常以租约形式实现，有过期时间，若客户端故障，锁最终会被释放。
- 操作的全序性 ：当资源受锁或租约保护时，需要一个 fencing 令牌来防止客户端