Consistency and Consensus (4-3) - Coordination Services & Summary

续 Day 21

协调服务 (Coordination Services)

像 Apache ZooKeeper 类型的专案通常会被描述为："分散式 key-values 储存" 或者 "负责协调和配置服务"，那为什麽 ZooKeeper 要实现共识演算法？它跟其他资料库又有什麽不同？今天就来了解下 ZooKeeper 做为协调服务能用在哪些地方。

用在分散式系统上

ZooKeeper 不是一般用途的资料库，它通常是其他资料库需要依赖的背景服务，像 Hbase、Hadoop YARN 和 Kafka (2.8 前) 等等，它被设计为处理很小量的 meta 资料，也因此资料能完全存在记忆体中，资料也会透过 全局顺序广播 (total order broadcast) 复制到其他节点上，除了全局顺序广播外，ZooKeeper 也能帮助我们建立分散式系统：

• 线性化原子操作 (Linearizable atomic operations)

  使用 原子比较并交换 (atomic compare-and-set) 操作，你能实现锁：若多个操作并发发生，只有一个操作能成功。

  另外分散式锁也能用来实现 Day 12 的 lease (租约)，它会有过期时间，以便在用户端故障能也能释放。

• 操作的全局排序 (Total ordering of operations)

  一样在 Day 12 提过，我们会用 击剑令牌 (Fencing token) 来避免用户端操作的冲突，而击剑令牌就是每次在获取锁时会增加的数字，而 ZooKeeper 的 zxid 和 cversion 就能充当 token，因为它能提供每个操作一个单调递增的 transaction ID。

• 错误检测 (Failure detection)

  用户端能在 ZooKeeper 上维护一个长时间的 session，当节点的 heartbeats 未发送或 timeout 时，ZooKeeper 可宣布该节点死亡，释放所有该节点占用的锁（ZooKeeper 称之为 ephemeral nodes)。

• 改变通知 (Change notifications)

  用户端能监控 ZooKeeper 的资料变化，当它发生改变时，会通知所有注册的节点们；所以节点会知道有谁加入丛集，或者有哪此节点死亡。

以上功能除了 线性化原子操作 需要用到共识算法外，其他功能造就了 ZooKeeper 很适合用在分散式系统的协调作用上。

用在节点工作分配上

首先是用在 leader 选举上，除了 single-leader 资料库以外，leader 也能用於安排 job 的时程或者需要类似角色安排工作的系统。

再者是用在分区资源管理（资料库、讯息系统、档案储存或分散式角色系统等等），透过 ZooKeeper 能帮忙你在新节点加入或故障时做 分区再平衡 (rebalancing partitions) 。

最後是用在共识投票上，只要固定节点数（通常是 3 或 5 台）的 ZooKeeper 就能实现上千台节点的多数决投票。

用在服务发现上

服务发现 (service discovery)，透过 ZooKeeper 或 Consul，能让用户端透过服务名称找到实际可提供服务的 IP，服务只要透过服务注册完，就能让其他服务找到。

结论

Day 14 ~ Day 22 介绍许多有关分散式系统的研究理论，包含 线性一致性 (Linearizability)、全局顺序广播、共识演算法、2PC、Lamport Timestamp 等等，虽然这些都有点难以理解，但它们都是实务上你曾看过的分散式系统中的词汇，这里应该算是个入门吧，帮助工程师多多少少有一些些了解，有能力的话再去看看那些相关原文吧。