續 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 等等，雖然這些都有點難以理解，但它們都是實務上你曾看過的分散式系統中的詞彙，這裡應該算是個入門吧，幫助工程師多多少少有一些些了解，有能力的話再去看看那些相關原文吧。