折騰了一週多終於跑起來了，貴在實踐。

參考地址：

指南地址
http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html
單機安裝
http://blog.csdn.net/done58/article/details/51004703
入門
http://www.tuicool.com/articles/JN73YrM
ZooKeeper  安裝部署
http://blog.csdn.net/huwei2003/article/details/49101269
叢集和偽叢集
http://coolxing.iteye.com/blog/1871009
叢集搭建
http://blog.csdn.net/beitiandijun/article/details/41802835

關於zookeeper的一些介紹

引子

雲端計算越來越流行的今天，單一機器處理能力已經不能滿足我們的需求，不得不採用大量的服務叢集。服務叢集對外提供服務的過程中，有很多的配置需要隨時更新，服務間需要協調工作，這些資訊如何推送到各個節點？並且保證資訊的一致性和可靠性？

眾所周知，分散式協調服務很難正確無誤的實現，它們很容易在競爭條件和死鎖上犯錯誤。如何在這方面節省力氣？Zookeeper是一個不錯的選擇。 Zookeeper背後的動機就是解除分散式應用在實現協調服務上的痛苦。本文在介紹Zookeeper的基本理論基礎上，用Zookeeper實現了一 個配置管理中心，利用Zookeeper將配置資訊分發到各個服務節點上，並保證資訊的正確性和一致性。
Zookeeper是什麼？

引用官方的說法：“Zookeeper是一個高效能，分散式的，開源分散式應用協調服務。它提供了簡單原始的功能，分散式應用可以基於它實現更高階 的服務，比如同步，配置管理，叢集管理，名空間。它被設計為易於程式設計，使用檔案系統目錄樹作為資料模型。服務端跑在java上，提供java和C的客戶端 API”。
Zookeeper總體結構

Zookeeper服務自身組成一個叢集(2n+1個服務允許n個失效)。Zookeeper服務有兩個角色，一個是leader，負責寫服務和資料同步，剩下的是follower，提供讀服務，leader失效後會在follower中重新選舉新的leader。

Zookeeper邏輯圖如下，

    客戶端可以連線到每個server，每個server的資料完全相同。
    每個follower都和leader有連線，接受leader的資料更新操作。
    Server記錄事務日誌和快照到持久儲存。
    大多數server可用，整體服務就可用。

Zookeeper資料模型

Zookeeper表現為一個分層的檔案系統目錄樹結構（不同於檔案系統的是，節點可以有自己的資料，而檔案系統中的目錄節點只有子節點）。

資料模型結構圖如下，

圓形節點可以含有子節點，多邊形節點不能含有子節點。一個節點對應一個應用，節點儲存的資料就是應用需要的配置資訊。
Zookeeper 特點

    順序一致性：按照客戶端傳送請求的順序更新資料。
    原子性：更新要麼成功，要麼失敗，不會出現部分更新。
    單一性 ：無論客戶端連線哪個server，都會看到同一個檢視。
    可靠性：一旦資料更新成功，將一直保持，直到新的更新。
    及時性：客戶端會在一個確定的時間內得到最新的資料。

Zookeeper運用場景

    資料釋出與訂閱 （我的業務用到這個特性，後面會有詳細介紹）

應用配置集中到節點上，應用啟動時主動獲取，並在節點上註冊一個watcher，每次配置更新都會通知到應用。

    名空間服務

分散式命名服務，建立一個節點後，節點的路徑就是全域性唯一的，可以作為全域性名稱使用。

    分散式通知/協調

不同的系統都監聽同一個節點，一旦有了更新，另一個系統能夠收到通知。

    分散式鎖

Zookeeper能保證資料的強一致性，使用者任何時候都可以相信叢集中每個節點的資料都是相同的。一個使用者建立一個節點作為鎖，另一個使用者檢測該節點，如果存在，代表別的使用者已經鎖住，如果不存在，則可以建立一個節點，代表擁有一個鎖。

    叢集管理

每個加入叢集的機器都建立一個節點，寫入自己的狀態。監控父節點的使用者會受到通知，進行相應的處理。離開時刪除節點，監控父節點的使用者同樣會收到通知。

常用命令的解釋

ZooKeeper 常用四字命令：

      ZooKeeper 支援某些特定的四字命令字母與其的互動。它們大多是查詢命令，用來獲取 ZooKeeper 服務的當前狀態及相關資訊。使用者在客戶端可以通過 telnet 或 nc 向 ZooKeeper 提交相應的命令

    1. 可以通過命令：echo stat|nc 127.0.0.1 2181 來檢視哪個節點被選擇作為follower或者leader
    2. 使用echo ruok|nc 127.0.0.1 2181 測試是否啟動了該Server，若回覆imok表示已經啟動。
    3. echo dump| nc 127.0.0.1 2181 ,列出未經處理的會話和臨時節點。
    4. echo kill | nc 127.0.0.1 2181 ,關掉server
    5. echo conf | nc 127.0.0.1 2181 ,輸出相關服務配置的詳細資訊。
    6. echo cons | nc 127.0.0.1 2181 ,列出所有連線到伺服器的客戶端的完全的連線 / 會話的詳細資訊。
    7. echo envi |nc 127.0.0.1 2181 ,輸出關於服務環境的詳細資訊（區別於 conf 命令）。
    8. echo reqs | nc 127.0.0.1 2181 ,列出未經處理的請求。
    9. echo wchs | nc 127.0.0.1 2181 ,列出伺服器 watch 的詳細資訊。
    10. echo wchc | nc 127.0.0.1 2181 ,通過 session 列出伺服器 watch 的詳細資訊，它的輸出是一個與 watch 相關的會話的列表。
    11. echo wchp | nc 127.0.0.1 2181 ,通過路徑列出伺服器 watch 的詳細資訊。它輸出一個與 session 相關的路徑。

1. 啟動ZK服務:       sh bin/zkServer.sh start
2. 檢視ZK服務狀態: sh bin/zkServer.sh status
3. 停止ZK服務:       sh bin/zkServer.sh stop
4. 重啟ZK服務:       sh bin/zkServer.sh restart

############################################################

叢集啟動shell指令碼 

#!/bin/sh

# crate file
touch /opt/redis/zoo1/data/myid
#write myid
echo "1" >> /opt/redis/zoo1/data/myid

echo "myid=" && cat /opt/redis/zoo1/data/myid
#start zoo1
cd /opt/redis/zoo1/zookeeper-3.4.8 && bin/zkServer.sh start
# crate file
touch /opt/redis/zoo2/data/myid
#write myid
echo "2" >> /opt/redis/zoo2/data/myid
#start zoo2
cd /opt/redis/zoo2/zookeeper-3.4.8 && bin/zkServer.sh start
# crate file
touch /opt/redis/zoo3/data/myid
#write myid
echo "3" >> /opt/redis/zoo3/data/myid
#start zoo3
cd /opt/redis/zoo2/zookeeper-3.4.8 && bin/zkServer.sh start


echo "啟動完畢,檢視啟動狀態"
cd /opt/redis/zoo1/zookeeper-3.4.8 && bin/zkServer.sh status

叢集停止的指令碼

#!/bin/sh

rm -rf /opt/redis/zoo1/data/myid
#stop zoo1
cd /opt/redis/zoo1/zookeeper-3.4.8 && ./bin/zkServer.sh stop

rm -rf /opt/redis/zoo2/data/myid
#stop zoo2
cd /opt/redis/zoo2/zookeeper-3.4.8 && ./bin/zkServer.sh stop

rm -rf /opt/redis/zoo3/data/myid
#stop zoo3
cd /opt/redis/zoo2/zookeeper-3.4.8 && ./bin/zkServer.sh stop