Zookeeper:
Zookeeper是一個高可用的分布式管理與協調架構，基于ZAB算法（原子消息廣播協定）的實作。該架構能夠很好的保證分布式環境中資料的一緻性。也隻是基于這樣的特性，使得Zookeeper成為了解決分布式一緻性問題的利器。
Zookeeper的特性：
①順序一緻性：從一個用戶端發起的事務請求，最終将會嚴格的按照其發起的順序被應用到zookeeper中去。
②原子性：所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一緻的，也就是說，要麼整個叢集所有的機器都成功應用了某一事務，要麼沒有應用，一定不會出現部分機器應用了該事務，而另一部分沒有應用的情況。
③單一視圖：無論用戶端連接配接的是哪一個zookeeper伺服器，其看到的伺服器端資料模型都是一緻的。
④可靠性：一旦伺服器成功地應用了一個事務，并完成對用戶端的響應，那麼該事務所引起的伺服器端狀态将會被一直保留，除非有另一個事務對其更改。
⑤實時性：通常所說的實時性就是指一旦事務被成功應用，那麼用戶端就能立刻從伺服器上擷取變更後的新資料，zookeeper僅僅能保證在一段時間内，用戶端最終能從伺服器端讀取最新的資料狀态。
Zookeeper原生api操作：
package com.qhong.zookeeper;
import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.Watcher.Event.EventType;
import org.apache.zookeeper.Watcher.Event.KeeperState;
import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.ZooDefs.Ids;
import java.util.concurrent.CountDownLatch;
public class ZookeeperBase {
/** zookeeper位址 */
//static final String CONNECT_ADDR = "192.168.80.88:2181,192.168.80.87:2181,192.168.80.86:2181";
static final String CONNECT_ADDR="192.168.1.108:2181";
/** session逾時時間 */
static final int SESSION_OUTTIME = 2000;//ms
/** 信号量，阻塞程式執行，用于等待zookeeper連接配接成功，發送成功信号 */
static final CountDownLatch connectedSemaphore = new CountDownLatch(1);
public static void main(String[] args) throws Exception{
ZooKeeper zk = new ZooKeeper(CONNECT_ADDR, SESSION_OUTTIME, new Watcher(){
@Override
public void process(WatchedEvent event) {
//擷取事件的狀态
KeeperState keeperState = event.getState();
EventType eventType = event.getType();
//如果是建立連接配接
if(KeeperState.SyncConnected == keeperState){
if(EventType.None == eventType){
//如果建立連接配接成功，則發送信号量，讓後續阻塞程式向下執行
connectedSemaphore.countDown();
System.out.println("zk 建立連接配接");
}
}
}
});
//進行阻塞
connectedSemaphore.await();
System.out.println("..");
//建立父節點
zk.create("/testRoot", "testRoot".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
//建立子節點，使用EPHEMERAL，主程式執行完成後該節點被删除，隻在本次會話内有效，可以用作分布式鎖。
zk.create("/testRoot/children", "children data".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
//擷取節點資訊
byte[] data = zk.getData("/testRoot", false, null);
System.out.println(new String(data));
System.out.println(zk.getChildren("/testRoot", false));
//修改節點的值，-1表示跳過版本檢查，其他正數表示如果傳入的版本号與目前版本号不一緻，則修改不成功，删除是同樣的道理。
zk.setData("/testRoot", "modify data root".getBytes(), -1);
byte[] data2 = zk.getData("/testRoot", false, null);
System.out.println(new String(data2));
System.out.println("zk children is exists");
//判斷節點是否存在
System.out.println(zk.exists("/testRoot/children", false));
System.out.println("delete children");
//删除節點
zk.delete("/testRoot/children", -1);
System.out.println(zk.exists("/testRoot/children", false));
zk.close();
}
} Output:
zk 建立連接配接
..
testRoot
[children]
modify data root
zk children is exists
1309,1309,1511968640670,1511968640670,0,0,0,99087986199232525,13,0,1309
delete children
null View Code
Curator版本問題：
Curator 2.x.x - compatible with both ZooKeeper 3.4.x and ZooKeeper 3.5.x
Curator 3.x.x - compatible only with ZooKeeper 3.5.x and includes support for new features such as dynamic reconfiguration, etc. Curator 2.x.x-相容兩個zk 3.4.x 和zk 3.5.x，Curator 3.x.x-相容相容zk 3.5。
應用場景：
1.統一伺服器名稱
命名伺服器事一個比較常用的應用場景，用戶端通過制定名字來擷取伺服器資源獲或提供者資訊等，被命名的可以伺服器位址，遠端對象。通過zk提供的建立節點的api，很容易建立一個全局唯一的path，這個path就可以做一個名稱，
dubbo使用zk就是用來做伺服器名稱。維護全局的服務位址清單。
服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL位址，這個操作就完成了服務的釋出。
服務消費者啟動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL位址， 并向/dubbo/${serviceName} /consumers目錄下寫入自己的URL位址。
注意，所有向ZK上注冊的位址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。 另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的資訊
2.統一配置管理
zk用戶端api提供了操作znode資料的功能。再分布式環境中我們可以配置檔案存放在znode上，不同的服務需要使用到哪些配置的時候可以直接從znode上去擷取。而且通過zk 的心跳極值，我們的配置檔案是可以做到動态配置的。一般的配置中心的做法是在系統啟動之後加載我們的記憶體當中，一但配置檔案需要做響應的調整的時候，需要重新開機服務進行load配置操作，但是很多的場景事我們隻需要更改一點點的内容就去重新開機服務，代價不可謂不大。但zk就可以避免這問題的發生，當配置檔案發生改變的時候，watch為通知到我們的服務對其修改操作。
3.分布式通知／協調
ZooKeeper中特有watcher注冊與異步通知機制，能夠很好的實作分布式環境下不同系統之間的通知與協調，實作對資料變更的實時處理。使用方法通常是不同系統都對ZK上同一個znode進行注冊，監聽znode的變化（包括znode本身内容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，并作出相應處理
1. 另一種心跳檢測機制：檢測系統和被檢測系統之間并不直接關聯起來，而是通過zk上某個節點關聯，大大減少系統耦合。
2.另一種系統排程模式：某系統有控制台和推送系統兩部分組成，控制台的職責是控制推送系統進行相應的推送工作。管理人員在控制台作的一些操作，實際上是修改了ZK上某些節點的狀态，而ZK就把這些變化通知給他們注冊Watcher的用戶端，即推送系統，于是，作出相應的推送任務。
3. 另一種工作彙報模式：一些類似于任務分發系統，子任務啟動後，到zk來注冊一個臨時節點，并且定時将自己的進度進行彙報（将進度寫回這個臨時節點），這樣任務管理者就能夠實時知道任務進度。
總之，使用zookeeper來進行分布式通知和協調能夠大大降低系統之間的耦合
4.共享鎖
分布式鎖，這個主要得益于ZooKeeper為我們保證了資料的強一緻性。鎖服務可以分為兩類，一個是 保持獨占，另一個是 控制時序。
1. 所謂保持獨占，就是所有試圖來擷取這個鎖的用戶端，最終隻有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實作。所有用戶端都去建立 /distribute_lock 節點，最終成功建立的那個用戶端也即擁有了這把鎖。
2. 控制時序，就是所有視圖來擷取這個鎖的用戶端，最終都是會被安排執行，隻是有個全局時序了。做法和上面基本類似，隻是這裡 /distribute_lock 已經預先存在，用戶端在它下面建立臨時有序節點（這個可以通過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節點（/distribute_lock）維持一份sequence,保證子節點建立的時序性，進而也形成了每個用戶端的全局時序。
5.隊列管理
隊列方面，簡單地講有兩種，一種是正常的先進先出隊列，另一種是要等到隊列成員聚齊之後的才統一按序執行。對于第一種先進先出隊列，和分布式鎖服務中的控制時序場景基本原理一緻，這裡不再贅述。 第二種隊列其實是在FIFO隊列的基礎上作了一個增強。通常可以在 /queue 這個znode下預先建立一個/queue/num 節點，并且指派為n（或者直接給/queue指派n），表示隊列大小，之後每次有隊列成員加入後，就判斷下是否已經到達隊列大小，決定是否可以開始執行了。這種用法的典型場景是，分布式環境中，一個大任務Task A，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子任務完成（就緒），那麼就去 /taskList 下建立自己的臨時時序節點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。
6.master選舉 在分布式環境中，相同的業務應用分布在不同的機器上，有些業務邏輯（例如一些耗時的計算，網絡I/O處理），往往隻需要讓整個叢集中的某一台機器進行執行，其餘機器可以共享這個結果，這樣可以大大減少重複勞動，提高性能，于是這個master選舉便是這種場景下的碰到的主要問題。 利用ZooKeeper的強一緻性，能夠保證在分布式高并發情況下節點建立的全局唯一性，即：同時有多個用戶端請求建立 /currentMaster 節點，最終一定隻有一個用戶端請求能夠建立成功。利用這個特性，就能很輕易的在分布式環境中進行叢集選取了。 另外，這種場景演化一下，就是動态Master選舉。這就要用到EPHEMERAL_SEQUENTIAL類型節點的特性了。 上文中提到，所有用戶端建立請求，最終隻有一個能夠建立成功。在這裡稍微變化下，就是允許所有請求都能夠建立成功，但是得有個建立順序，于是所有的請求最終在ZK上建立結果的一種可能情況是這樣： /currentMaster/{sessionId}-1 ,/currentMaster/{sessionId}-2,/currentMaster/{sessionId}-3 ….. 每次選取序列号最小的那個機器作為Master，如果這個機器挂了，由于他建立的節點會馬上小時，那麼之後最小的那個機器就是Master了。
1.在搜尋系統中，如果叢集中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引資料一緻。是以讓叢集中的Master來進行全量索引的生成，然後同步到叢集中其它機器。另外，Master選舉的容災措施是，可以随時進行手動指定master，就是說應用在zk在無法擷取master資訊時，可以通過比如http方式，向一個地方擷取master。
2.在Hbase中，也是使用ZooKeeper來實作動态HMaster的選舉。在Hbase實作中，會在ZK上存儲一些ROOT表的位址和HMaster的位址，HRegionServer也會把自己以臨時節點（Ephemeral）的方式注冊到Zookeeper中，使得HMaster可以随時感覺到各個HRegionServer的存活狀态，同時，一旦HMaster出現問題，會重新選舉出一個HMaster來運作，進而避免了HMaster的單點問題
選舉問題：
新叢集啟動時候的選舉過程，啟動的時候就是根據zoo.cfg裡的配置，向各個節點廣播投票，一般都是選投自己。然後收到投票後就會進行進行判斷。如果某個節點收到的投票數超過一半，那麼它就是leader了。
一個問題：
一個叢集有3台機器，挂了一台後的影響是什麼？挂了兩台呢？
挂了一台：挂了一台後就是收不到其中一台的投票，但是有兩台可以參與投票，按照上面的邏輯，它們開始都投給自己，後來按照選舉的原則，兩個人都投票給其中一個，那麼就有一個節點獲得的票等于2，2 > (3/2)=1 的，超過了半數，這個時候是能選出leader的。
挂了兩台： 挂了兩台後，怎麼弄也隻能獲得一張票， 1 不大于 (3/2)=1的，這樣就無法選出一個leader了。 圖檔：