我最近一直在閱讀Paxos論文，FLP定理等，並評估Apache Zookeeper的項目。我也一直在通過Chubby（谷歌的分佈式鎖定服務）和其上的各種文獻。我對Zookeeper的基本用途是爲分佈式系統實現複製和一般協調。Zookeeper/Chubby -vs- MySql NDB
我只是想知道，Zookeeper或胖乎乎的分佈式鎖定系統帶來了什麼具體優勢。基本上我只是想知道爲什麼我不能只使用MySQL NDB集羣。我一直聽說MySQL有很多複製問題。我希望有更多關於這個問題的經驗可以爲我們提供一些啓示。
在此先感謝..
我要求一個簡單的列表：
這取決於那種你所管理的數據的。你要去的規模和容錯能力。
我可以從ZooKeeper的角度回答。在開始之前，我應該提到ZooKeeper不是一個胖乎乎的克隆。具體而言，它不直接鎖定。它也是根據不同的訂購和性能要求而設計的。
在ZooKeeper的系統狀態的完整副本駐留在內存中。使用原子廣播協議複製更改，並在處理之前由大多數ZooKeeper服務器同步到磁盤（使用更改日誌）。由於這種ZooKeeper具有確定性的性能，只要大多數服務器啓動，就可以容忍故障。即使發生停電等嚴重故障，只要大部分服務器恢復正常工作，系統狀態仍會保留。存儲的信息是ZooKeeper通常被認爲是系統的基本事實，所以這種一致性和耐久性保證是非常重要的。
的其他東西，動物園管理員爲您提供了與監控動態協調的狀態做。短暫節點使您可以輕鬆進行故障檢測和組成員資格。訂購保證允許您做領導選舉和客戶端鎖定。最後，手錶允許您監視系統狀態並快速響應系統狀態的變化。
所以，如果你需要管理和動態配置響應，檢測故障，當選的領導人等的ZooKeeper是你在找什麼。如果您需要存儲大量數據，或者您需要該數據的關係模型，那麼MySQL是更好的選擇。
您是否可以詳細說明「爲不同的訂購和性能要求而設計」，對於熟悉w /胖乎乎的紙張的人來說？ – jbellis 2010-02-24 04:09:37
不幸的是我不能說得太多，因爲我只從紙上了解Chubby。他們指出的其中一件事是Chubby被設計用於粒度協調。對於ZooKeeper，我們希望具有足夠高的性能，以便應用程序可以廣泛使用它。出於這個原因，我們交易了有序操作的同步更新。 例如，在寫入完成之前，Chubby會通知所有客戶端發生更改。 ZooKeeper放鬆了一下。寫入完成後，更改通知會排隊等待到ZooKeeper客戶端，但可能無法傳送。 – 2010-02-24 07:32:57
對不起，評論限制太短。 ZooKeeper操作無需等待。這意味着一個客戶端不能阻止另一個客戶端操作的執行。這也意味着我們可以獲得高吞吐量的良好執行流水線。我們的寫吞吐量在每秒數萬個操作數的範圍內，讀取吞吐量達數十萬。除了可能需要使用sync（）方法的幾個角落案例之外，大部分權衡對開發人員來說並不明顯。 – 2010-02-24 07:53:02
與MySQL的InnoDB提供一個好的通用解決方案，並且可能會在不太昂貴的硬件上很容易地滿足您的性能要求。它可以很容易地處理與雙面四核心框與體面的磁盤每秒數千更新。內置的異步複製將爲您提供大部分的可用性需求，但如果主服務器出現故障，您可能會丟失幾秒鐘的數據。當主服務器被修復時，這些丟失的數據中的一部分可能是可恢復的，或者可能從應用程序日誌中恢復：您是否可以容忍這取決於系統的工作方式。減少損失 - 但速度更慢 - 另一種方法是使用MySQL Innodb與主磁盤和故障轉移單元之間的共享磁盤：在這種情況下，故障轉移單元將在主服務器出現故障且不丟失數據時接管磁盤 - 只要主服務器沒有出現某種磁盤災難。如果共享磁盤不可用，則可以使用DRBD通過在寫入故障轉移單元時同步將磁盤塊複製到故障轉移單元來模擬此情況：這可能會影響性能。
使用Innodb和以上覆制解決方案之一將您的數據複製到您的故障轉移單元，這是恢復問題解決的一大部分，但需要額外粘合劑來重新配置系統以使故障轉移單元保持在線狀態，線。這通常使用RHCS或Pacemaker或Heartbeat（在Linux上）或MS Cluster for Windows等羣集系統執行。這些系統都是工具包，您只需將自己的手建設成適合您環境的解決方案即可。但是，對於所有這些系統，在系統發現主服務器出現故障時會有短暫的中斷時間，並重新配置系統以使用故障切換單元。這可能需要幾十秒：試圖減少這種情況可能會使您的故障檢測系統過於敏感，並且您可能會發現系統因不必要的故障而失敗。
向上移動，MySQL NDB旨在減少恢復時間，並在一定程度上幫助擴展數據庫以提高性能。但是，MySQL NDB的適用範圍相當狹窄。系統將關係數據庫映射到分佈式哈希表上，因此對於涉及跨表的多個連接的複雜查詢，MySQL組件和存儲組件（NDB節點）之間存在相當多的流量，從而使複雜查詢運行緩慢。然而，適合的查詢確實運行得非常快。我已經看了幾次這個產品，但我現有的數據庫太複雜了，以至於不能很好地適應，並且需要很多重新設計才能獲得良好的性能。但是，如果您正處於新系統的設計階段，那麼如果您隨時可以考慮到其約束條件，則NDB將運行良好。另外，你可能會發現需要很多機器來提供一個好的NDB解決方案：幾個MySQL節點加上3個或更多的NDB節點 - 儘管如果你的性能需求不是太大，MySQL和NDB節點可以共存。
即使MySQL的NDB不能與總用地損失應付 - 火在數據中心，管理錯誤等。在這種情況下，你通常需要運行一個災難恢復站點的另一複製流。這通常會異步完成，因此站點間鏈接上的連接點不會導致整個數據庫停滯。這是與NDB的地理複製選項（在收費的電信版本中）一起提供的，但我認爲MySQL 5.1及以上版本可以提供本地版本。
不幸的是，我知之甚少動物園管理員和圓滾滾的。希望別人能夠拿起這些方面。
這是一個非常翔實的帖子.. thanx。 希望有Zookeeper經驗的人也會分享他們的想法。 – 2010-02-22 11:33:28
這個問題很難回答，不知道你想要達到什麼。簡單的MySQL複製（甚至不使用NDB）很可能就足夠了。 在大多數數據庫體系結構中，要回答的關鍵問題是 1）什麼是我的恢復時間目標（即，我需要多長時間才能從主數據庫崩潰中恢復） 2）什麼是我的恢復點目標（即如何在主數據庫崩潰的情況下，我可能會丟失大量數據） 對這些目標的容差越嚴格，解決方案就越複雜（並且代價昂貴）。 – Martin 2010-02-22 08:24:44
Thanx martin ...我只是用我的要求更新了我的問題。 – 2010-02-22 08:34:07