iT邦幫忙

2021 iThome 鐵人賽

DAY 22
0
AI & Data

資料工程師修煉之路 Part II系列 第 22

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


上一篇
Consistency and Consensus (4-2) - Fault-Tolerant Consensus
下一篇
Batch Processing (1) - Batch Processing with Unix Tools
系列文
資料工程師修煉之路 Part II30

尚未有邦友留言

立即登入留言