Apache Helix讓分散式管理更方便

banq發表於2013-10-17
Apache分散式
在NoSQL和大資料領域，隨著爆炸式的資料增長，分散式系統的數量有了顯著增長。 多年來，我們在LinkedIn已經建立了一個分散式系統，該系統上執行多臺伺服器的叢集並保證容錯性 - 保證在出現伺服器故障和網路問題情況下系統是可用的 - 這是任何分散式系統的關鍵。 這樣才能透過水平的橫向擴充套件性和無縫的叢集擴充套件處理日益增加的工作量。

在一組自治的過程中的每一個被稱為一個例項instance，共同構成一個叢集。 與參與者共同執行或支援一個任務，這被稱為資源resource。 資源是一個邏輯實體，可以跨越許多例項。 例如，資料庫，主題topic，索引或任何計算/服務的任務可以被對映到一個資源。 資源可以進一步細分成子資源或子任務，被稱為分割槽partitions。 分割槽是和一個例項相關的資源的最主要組成部分，因此不可能跨越多個例項，的一個例項，這意味著一個分割槽不能跨越多個例項，分割槽可以有多個副本以支援容錯和/或可擴充套件性,每個副本都稱為複製replica。

上述的術語是很通用的可以對映到任何分散式系統。 但是，在具體不同的分散式系統，它們的功能和行為顯著不同。 例如，一個搜尋系統，用於支援查詢的行為肯定和讀取可變資料行為是不同的。 因此，為了有效地描述一個分散式系統的行為，我們需要定義資源和分割槽的各種狀態，用來捕捉各種有效狀態和狀態轉換。 Helix使用一個有限狀態機 （FSM）實現這個功能。

如下圖：

[img index=1]

FSM本身描述所有系統中的不變數是不夠的 - 我們仍然需要一種方法來捕捉所需的系統的行為時，叢集拓撲結構的變化。 例如，當一個節點出現故障時，我們可以選擇建立新的副本，更改現有副本的狀態。 當新節點新增到叢集中，我們可以重新立即或逐步地分割槽分配到新節點。 這些都是常見的問題，但是對於人工維護來說對付所有可能出現的情況是困難的。

Helix可以透過約束constraints 和目標Objectives，狀態機中每個狀態可以定義為約束，你可以指定約束的不同粒度，比如分割槽，資源，例項，叢集。

下面是約束和目標的一些舉例：
狀態約束State constraints:
分割槽週期Partition scope: 1 Master, 2 Slave
例項週期Instance scope: 每個節點最多10個分割槽

狀態切換約束Transition constraints:
在cluster=5的狀態切換最大bootstrap(透過網路複製資料)的數目是多少。

目標Objectives:
分割槽的均勻分佈
在不同節點之間複製。
以最小執行對一個節點進行failure/addition/removal釋出

基於這些概念，叢集管理的定義如下：
對於一組例項和資源，並帶有系統的狀態約束，這種情況下，計算滿所有足約束的實現分割槽到例項的分配方式。

Helix就是這樣一個使用者簡化管理分散式系統的叢集管理框架。

Distributed Systems Get Simpler with Apache Helix

[該貼被banq於2013-10-17 12:28修改過]

相關文章