動物園管理員如下一個簡單的客戶端 - 服務器模型,其中客戶端節點(即,機器),使使用該服務,和服務器是提供服務的節點。 ZooKeeper服務器的集合形成一個ZooKeeper集合。在任何時候,一個ZooKeeper客戶端連接到一個ZooKeeper服務器。每個ZooKeeper服務器可以同時處理大量的客戶端連接。每個客戶端週期性地向它連接的ZooKeeper服務器發送ping命令,讓它知道它是活着的並且已連接。有問題的ZooKeeper服務器會響應ping的確認,表明服務器也處於活動狀態。當客戶端在指定的時間內沒有收到服務器的確認信息時,客戶端連接到集成中的另一臺服務器,客戶端會話將透明地傳輸到新的ZooKeeper服務器。 Check this瞭解動物園管理員架構
當客戶端請求讀取特定znode的內容時,讀取發生在客戶端連接到的服務器上。因此,由於只涉及集合中的一臺服務器,所以讀取快速且可擴展。但是,要成功完成寫入操作,ZooKeeper集合的絕大多數節點必須可用。當ZooKeeper服務啓動時,來自整體的一個節點被選爲領導者。當客戶端發出寫請求時,連接的服務器將請求傳遞給領導。然後該領導者向集合的所有節點發出相同的寫入請求。如果絕大多數節點(也稱爲仲裁)成功響應此寫入請求,則認爲寫入請求已成功。然後成功的返回代碼返回給發起寫入請求的客戶端。如果法團的法定節點在集體中不可用,則ZooKeeper服務不起作用。 Check this瞭解寫操作的投票過程
爲了服務的可靠性和可擴展性,它被複制到一組機器上。 ZooKeeper使用着名的Paxos算法的一個版本來保持副本的一致性。
動物園管理員給出以下稠度從客戶端保證
順序一致性更新將在它們被髮送的順序來應用。
原子性更新成功或失敗 - 沒有部分結果。
單個系統映像無論服務器連接到哪個服務器,客戶端都會看到相同的服務視圖。
可靠性一旦應用更新,它將一直持續到此時間,直到客戶機覆蓋更新爲止。這個保證有兩個推論:
及時性該系統的客戶端視圖保證在一定的時間範圍內(大約幾十秒)是最新的。客戶可以在此範圍內看到任何系統更改,或者客戶端將檢測到服務中斷。
以下是回答您的問題
問題1:投票是寫操作是否應該被提交或不。
問題2:在動物園管理員合奏客戶端和服務器之間的通信發生在使用ZAB protocol
問題3通過消息交換的TCP連接:對於服務是可靠的和容錯,數據必須複製到服務器的法定人數。
其實在兩階段提交中也有投票。追隨者「投票」提交。如果有足夠的追隨者「投」了提交,那麼主人可以提交寫入。在這種情況下,可以保證在每個仲裁(超過一半的服務器)中至少有一臺服務器已經看到提交。 – 2011-01-28 14:19:59