Zab (ZooKeeper Atomic Broadcast)

Zab 
(ZooKeeper Atomic Broadcast) 
(ZooKeeper原子廣播協議，一種分佈式一致性協議) 


 
目錄 

 
Zab(ZooKeeper原子廣播協議，一種分佈式一致性協議), ZooKeeper用它來傳播擴展由ZooKeeper領導者（leader）引發的狀態變更。 
Zab實現了一個簡單的全序廣播協議（A simple totally ordered broadcast protocol，一種分佈式一致性協議） 
A simple totally ordered broadcast protocol，一種分佈式一致性協議可參考文檔下載
1 介紹 
在雅虎，我們開發了一個高性能，高可用的協作服務Zookeeper，允許大規模應用程序執行協調任務如領導人選舉，狀態傳播，以及約定集會。此服務實現了一個分層空間的數據節點（znode），客戶端使用它來實現它們的協調工作。我們發現這個服務性能非常靈活，很容易滿足我們在雅虎的網站規模、關鍵任務應用程序的生產需求。ZooKeeper沒有使用鎖，而是採用wait-free共享數據對象來保證在這些對象上操作的順序。 

2 要求 
我們假設一組過程，這些過程實現了原子廣播協議並且使用該協議。在Zookeeper中，爲了保證正確的轉換爲冪等請求，必須在同一時刻只能有一個領導者（leader），因此，通過協議實現，我們將其中一個過程升級爲領導者這樣的一個過程。當我們介紹協議的更多詳細細節時，我們會更多的討論它。 
關於廣播協議，Zoopkeeper要求如下： 下載
可靠傳遞 
如果某個服務器成功投遞了一個消息m，那麼，所有正確的服務器終將成功投遞這個消息。 
全序 
如果某個服務器成功投遞了消息a和b，並且消息a比消息b先投遞，那麼每個投遞消息a和b的服務器在投遞消息時，消息a比消息b先投遞。 
因果順序 
如果消息a有原因地先於消息b投遞，並且都成功投遞，那麼消息a必須順序先於b投遞。 
爲了保證正確性，Zoopkeeper還要求以下前綴屬性： 下載
前綴屬性 
如果消息m是領導者（leader）L投遞的最後一個消息，在消息m被投遞之前的任何被領導者（leader）L提議的消息也必須是投遞成功的。 
備註：一個過程可能被選舉多次，但每次選舉出來作爲領導者（leader），對前綴屬性所起的作用被認爲是不同的領導者（leader）。 
通過以下3個保證，我們能維護正確的ZooKeeper數據庫副本： 
1、 可靠性和全序保證確保所有的副本有一個一致的狀態。 
2、 使用Zab協議，從應用程序的角度看，因果順序確保副本狀態的正確 
3、 領導者根據收到的請求向數據庫提出更新。 
Zab考慮了兩種類型的因果關係。注意下這個，這個很重要。 
1、 如果兩個消息a和b，被同一個服務器發送，並且消息a先於消息b被提議，我們說消息a有原因地先於b。 
2、 Zab假設同一時刻只有一個領導者（leader）能提交提議。如果領導者發生變化，任何之前提議的消息有原因地先於被新領導者（leader）提議的消息。 
因果關係違例。 下載


其他性能要求如下： 
低延時 
突發性的高吞吐量 
平滑的故障處理 


3 爲什麼需要另一種協議 

4 協議 
Zab協議包括兩種模式：恢復（recovery）模式和廣播（broadcast）模式。