我一直在想爲什麼ZooKeeper需要合奏中的大部分機器才能工作。假設我們有一個非常簡單的3臺機器--A，B，C組合。爲什麼ZooKeeper需要大部分運行？
當A失敗時，新領導人被選中 - 罰款，一切正常。當另一個人死亡時，讓我們說B，服務不可用。是否有意義？爲什麼機器C不能單獨處理所有事情，直到A和B再次起來？
由於一體機就足以完成所有的工作（例如單機集成正常工作）...
有原因的ZooKeeper是這樣設計什麼特別的原因？有沒有一種方法可以配置ZooKeeper，例如當至少有一個N啓動時總是可用的？
編輯： 也許有一種方法可以應用自定義算法的領導者選擇？或者定義法定人數的大小？
在此先感謝。
Zookeeper旨在可靠地分配東西。如果系統網絡分割，那麼您不希望這兩個半部分獨立運行並且可能不同步，因爲當故障解決後，它不知道該做什麼。如果你在它少於多數時拒絕運作，那麼你可以放心，當一個失敗得到解決時，一切都會立即恢復，而不需要進一步干預。
在我的例子中，我沒有對系統進行分割 - 只有3個節點中的兩個處於關閉狀態。如果殺死任何節點，這並不意味着系統會被分成2/3/n一次 - 它仍然是具有較少節點的同一個系統。系統應該關閉，只有當所有節點都是。即使單個節點也應該能夠處理客戶端的讀/寫請求（並且它背景，它應該不斷嘗試重新連接到其他節點）。具有50％工作節點的ZooKeeper服務將會停止運行，這是否有意義？如果我們有100臺機器，我們仍然有50個節點來處理所有事情......但系統不可用。 –
用「isolate」替換「kill」一詞，您會發現在出現網絡故障（但機器仍在運行）的情況下，發現自己不屬於大多數的節點在邏輯上離線。與機器關機相比，網絡故障是更常見的現實世界情景。 – slebetman
@MichałSzkudlarek - 你沒有意識到的一點是，Zookeeper節點不知道丟失的節點是否完全關閉，或者由於網絡故障而無法訪問。所以他們的行爲就像是網絡故障，以避免出現問題時出現問題得到修復。 –
獲得多數票的原因是爲了避免稱爲「裂腦」的問題。
基本上在網絡故障中，您不希望系統的兩個部分像往常一樣繼續。你希望一個繼續，另一個理解它不是集羣的一部分。
有兩種主要方法可以實現，一種是持有共享資源，例如共享磁盤，其中領導者持有鎖，如果您不能看到您是羣集一部分的鎖'退出。如果你持有鎖定，那麼你就是領導者，如果你不這樣做。這種方法的問題是您需要共享資源。
另一種防止裂腦的方法是多數計數，如果你得到足夠的選票，你是領導者。這仍然適用於兩個節點（法定人數爲3），領導者稱其爲領導者，另一個作爲「證人」的節點也同意。這種方法是可取的，因爲它可以在無共享體系結構中工作，事實上這正是Zookeeper使用的方式。正如Michael所說的，節點無法知道它是否看不到羣集中的其他節點的原因是因爲這些節點或者存在網絡問題 - 安全的選擇就是說沒有法定人數。
讓我們來看一個示例，說明如果法定人數（大多數運行中的服務器）太小，情況會如何變化。
假設我們有五臺服務器，並且法定人數可以是任意兩臺服務器的集合。現在說服務器s1和s2確認他們已經複製了創建znode/z的請求。該服務返回給客戶說znode已經創建。現在假設服務器s1和s2在任意長的時間內與其他服務器和客戶端分開，然後纔有機會將新的znode複製到其他服務器。在這種狀態下的服務能夠取得進展，因爲有三臺服務器可用，根據我們的假設它確實只需要兩臺服務器，但這三臺服務器從未見過新的znode/z。因此，創建/ z的請求不是持久的。
這是一個裂腦情景的例子。爲避免此問題，在此示例中，法定人數的大小必須至少爲3，這是集合中五臺服務器中的大多數。爲了取得進展，整個團隊至少需要三臺服務器。要確認更新狀態的請求已成功完成，此集合還要求至少有三臺服務器確認它們已複製它。
您是否找到了改變當前領導者選擇算法的方法？我發現還有一點令人沮喪的是，爲3臺機器支付了200K的費用，這些機器應該能夠消除單點故障點發現自己基本處於相同位置的風險...... – dcg
@dcg不，我甚至沒有嘗試過找到一個解決方法，因爲在閱讀我的問題的答案後，我瞭解了ZooKeeper的方法，這看起來很合理。 –