初步認識zookeeper
問題的引入
隨著服務的模組化分散式架構的衍出，叢集化越來越嚴重
1.協議地址的維護
傳統方式模組間互相呼叫通過webservice方式，但是存在好多個訂單服務，使用者模組呼叫訂單服務通過http：//****?wsdl路徑訪問一個訂單服務就要好多個這種路徑，那麼怎麼維護這個路徑？
2.負載均衡機制
存在n個訂單服務，不能指望一個訂單服務處理所有請求
3.服務動態上下線感知
假如其中一個訂單down掉怎麼感知，從而不往這個服務傳送請求？
這個時候我們就需要一箇中間件所有訂單服務註冊到中介軟體上，使用者模組只需要與中介軟體互動獲取一個地址簿由中介軟體進行轉發維護管理
這個中介軟體就是zookeeper(分散式協調服務)
本例
我們可以建立一個orderservice節點
節點下維護了所有訂單地址
分散式請求牽扯到共享資源的訪問，單程序模組我們可以用執行緒鎖控制，但是分散式環境是多程序服務，就需要一箇中間件來維護共享資源。zookeeper就起到這個作用
但是為了保證zookeeper的高可用我們基本上不會只用一個zookeeper，這就形成了一個zookeeper叢集。假設所有的訂單服務都往叢集中註冊，部分註冊到zookeeperA中部分註冊到zookeeperB中這就牽扯到zookeeper的同步問題
zookeeper叢集角色leader，follower 所有的事務請求在leader所有的寫請求在follower
當事務請求發生在leader時，leader要同步給follower(因為模組可以訪問任意zookeeper，要保證資料一致性)
資料同步問題怎麼解決呢？
CAP理論(2pc最終一致性解決)，不可能大到強一致性，保證高效能高可用
中心化
我們上邊講到zookeeper叢集是中心化的，即存在leader follower，那麼什麼是中心化？
假設我們專案團隊是一個叢集，那麼我們的專案經理就是一個leader ,如果leader有問題了就沒人派發任務了。