記得在大約在2006年的時候Google出了Chubby來解決分佈一致性的問題(distributed consensus problem)，所有叢集中的伺服器透過Chubby最終選出一個Master Server ，最後這個Master Server來協調工作。簡單來說其原理就是：在一個分散式系統中，有一組伺服器在運行同樣的程式，它們需要確定一個Value，以那個伺服器提供的資訊為主/為準，當這個伺服器經過n/2+1的方式被選出來後，所有的機器上的Process都會被通知到這個伺服器就是主伺服器 Master伺服器，大家以他提供的資訊為準。很想知道Google Chubby中的奧妙，可惜人家Google不開源，自家用。但是在2009年3年以後沉默已久的Yahoo在Apache上推出了類似的產品ZooKeeper，並且在Google原有Chubby的設計思想上做了一些改進，因為ZooKeeper並不是完全遵循Paxos協議，而是基於自身設計並最佳化的一個2 phase commit的協議，如圖所示：ZooKeeper跟Chubby一樣用來存放一些相互協作的資訊(Coordination)，這些資訊比較小一般不會超過1M，在zookeeper中是以一種hierarchical tree的形式來存放，這些具體的Key/Value資訊就store在tree node中。當有事件導致node資料，例如：變更，增加，刪除時，Zookeeper就會呼叫 triggerWatch方法，判斷當前的path來是否有對應的監聽者(watcher),如果有watcher，會觸發其process方法，執行process方法中的業務邏輯，如圖：應用例項 ZooKeeper有了上述的這些用途，讓我們設想一下，在一個分散式系統中有這這樣的一個應用： 2個任務工廠(Task Factory)一主一從，如果從的發現主的死了以後，從的就開始工作，他的工作就是向下面很多臺代理(Agent)傳送指令，讓每臺代理(Agent)獲得不同的賬戶進行分散式平行計算，而每臺代理(Agent)中將分配很多帳號，如果其中一臺代理(Agent)死掉了，那麼這臺死掉的代理上的賬戶就不會繼續工作了。上述，出現了3個最主要的問題： 1.Task Factory 主/從一致性的問題 2.Task Factory 主/從心跳如何用簡單+穩定 或者2者折中的方式實現。 3.一臺代理(Agent)死掉了以後，一部分的賬戶就無法繼續工作，需要通知所有線上的代理(Agent)重新分配一次帳號。怕文字闡述的不夠清楚，畫了系統中的Task Factory和Agent的大概系統關係，如圖所示：OK，讓我們想想ZooKeeper是不是能幫助我們去解決目前遇到的這3個最主要的問題呢？解決思路1. 任務工廠Task Factory都連線到ZooKeeper上，建立節點，設定對這個節點進行監控，監控方法例如： event= new WatchedEvent(EventType.NodeDeleted, KeeperState.SyncConnected, "/TaskFactory"); 這個方法的意思就是隻要Task Factory與zookeeper斷開連線後，這個節點就會被自動刪除。2.原來主的任務工廠斷開了TCP連線，這個被建立的/TaskFactory節點就不存在了，而且另外一個連線在上面的Task Factory可以立刻收到這個事件(Event)，知道這個節點不存在了，也就是說主TaskFactory死了。3.接下來另外一個活著的TaskFactory會再次建立/TaskFactory節點，並且寫入自己的ip到znode裡面，作為新的標記。4.此時Agents也會知道主的TaskFactory不工作了，為了防止系統中大量的丟擲異常，他們將會先把自己手上的事情做完，然後掛起，等待收到Zookeeper上重新建立一個/TaskFactory節點，收到 EventType.NodeCreated 型別的事件將會繼續工作。5.原來從的TaskFactory 將自己變成一個主TaskFactory，當系統管理員啟動原來死掉的主的TaskFactory，世界又恢復平靜了。6.如果一臺代理死掉，其他代理他們將會先把自己手上的事情做完，然後掛起，向TaskFactory傳送請求，TaskFactory會重新分配(sharding)帳戶到每個Agent上了，繼續工作。
記得在大約在2006年的時候Google出了Chubby來解決分佈一致性的問題(distributed consensus problem)，所有叢集中的伺服器透過Chubby最終選出一個Master Server ，最後這個Master Server來協調工作。簡單來說其原理就是：在一個分散式系統中，有一組伺服器在運行同樣的程式，它們需要確定一個Value，以那個伺服器提供的資訊為主/為準，當這個伺服器經過n/2+1的方式被選出來後，所有的機器上的Process都會被通知到這個伺服器就是主伺服器 Master伺服器，大家以他提供的資訊為準。很想知道Google Chubby中的奧妙，可惜人家Google不開源，自家用。但是在2009年3年以後沉默已久的Yahoo在Apache上推出了類似的產品ZooKeeper，並且在Google原有Chubby的設計思想上做了一些改進，因為ZooKeeper並不是完全遵循Paxos協議，而是基於自身設計並最佳化的一個2 phase commit的協議，如圖所示：ZooKeeper跟Chubby一樣用來存放一些相互協作的資訊(Coordination)，這些資訊比較小一般不會超過1M，在zookeeper中是以一種hierarchical tree的形式來存放，這些具體的Key/Value資訊就store在tree node中。當有事件導致node資料，例如：變更，增加，刪除時，Zookeeper就會呼叫 triggerWatch方法，判斷當前的path來是否有對應的監聽者(watcher),如果有watcher，會觸發其process方法，執行process方法中的業務邏輯，如圖：應用例項 ZooKeeper有了上述的這些用途，讓我們設想一下，在一個分散式系統中有這這樣的一個應用： 2個任務工廠(Task Factory)一主一從，如果從的發現主的死了以後，從的就開始工作，他的工作就是向下面很多臺代理(Agent)傳送指令，讓每臺代理(Agent)獲得不同的賬戶進行分散式平行計算，而每臺代理(Agent)中將分配很多帳號，如果其中一臺代理(Agent)死掉了，那麼這臺死掉的代理上的賬戶就不會繼續工作了。上述，出現了3個最主要的問題： 1.Task Factory 主/從一致性的問題 2.Task Factory 主/從心跳如何用簡單+穩定 或者2者折中的方式實現。 3.一臺代理(Agent)死掉了以後，一部分的賬戶就無法繼續工作，需要通知所有線上的代理(Agent)重新分配一次帳號。怕文字闡述的不夠清楚，畫了系統中的Task Factory和Agent的大概系統關係，如圖所示：OK，讓我們想想ZooKeeper是不是能幫助我們去解決目前遇到的這3個最主要的問題呢？解決思路1. 任務工廠Task Factory都連線到ZooKeeper上，建立節點，設定對這個節點進行監控，監控方法例如： event= new WatchedEvent(EventType.NodeDeleted, KeeperState.SyncConnected, "/TaskFactory"); 這個方法的意思就是隻要Task Factory與zookeeper斷開連線後，這個節點就會被自動刪除。2.原來主的任務工廠斷開了TCP連線，這個被建立的/TaskFactory節點就不存在了，而且另外一個連線在上面的Task Factory可以立刻收到這個事件(Event)，知道這個節點不存在了，也就是說主TaskFactory死了。3.接下來另外一個活著的TaskFactory會再次建立/TaskFactory節點，並且寫入自己的ip到znode裡面，作為新的標記。4.此時Agents也會知道主的TaskFactory不工作了，為了防止系統中大量的丟擲異常，他們將會先把自己手上的事情做完，然後掛起，等待收到Zookeeper上重新建立一個/TaskFactory節點，收到 EventType.NodeCreated 型別的事件將會繼續工作。5.原來從的TaskFactory 將自己變成一個主TaskFactory，當系統管理員啟動原來死掉的主的TaskFactory，世界又恢復平靜了。6.如果一臺代理死掉，其他代理他們將會先把自己手上的事情做完，然後掛起，向TaskFactory傳送請求，TaskFactory會重新分配(sharding)帳戶到每個Agent上了，繼續工作。