zookeeper集群基礎(chǔ)知識與linux系統(tǒng)環(huán)境的搭建 - 全文

1.認(rèn)識zookeeper

1.1 zookeeper是什么？

ZooKeeper是源代碼開放的分布式協(xié)調(diào)服務(wù)，由雅虎創(chuàng)建，是Google Chubby的開源實現(xiàn)。ZooKeeper是一個高性能的分布式數(shù)據(jù)一致性解決方案，它將那些復(fù)雜的、容易出錯的分布式一致性服務(wù)封裝起來，構(gòu)成一個高效可靠的原語集，并提供一系列簡單易用的接口給用戶使用；
知識要點：
1、源代碼開放
2、是分布式協(xié)調(diào)服務(wù)，它解決分布式數(shù)據(jù)一致性問題
A：順序一致性 B：原子性 C：單一視圖
D：可靠性 E：實時性
3、高性能
4、我們可以通過調(diào)用ZooKeeper提供的接口來解決一些分布式應(yīng)用中的實際問題

1.2 zookeeper的應(yīng)用場景

1.2.1.數(shù)據(jù)發(fā)布/訂閱
數(shù)據(jù)發(fā)布/訂閱顧名思義就是一方把數(shù)據(jù)發(fā)布出來，另一方通過某種手段可以得到這些數(shù)據(jù)
通常數(shù)據(jù)訂閱有兩種方式：推模式和拉模式，推模式一般是服務(wù)器主動向客戶端推送信息，拉模式是客戶端主動去服務(wù)器獲取數(shù)據(jù)（通常是采用定時輪詢的方式），
ZK采用兩種方式相結(jié)合
發(fā)布者將數(shù)據(jù)發(fā)布到ZK集群節(jié)點上，訂閱者通過一定的方法告訴服務(wù)器，我對哪個節(jié)點的數(shù)據(jù)感興趣，那服務(wù)器在這些節(jié)點的數(shù)據(jù)發(fā)生變化時，就通知客戶端，客戶端得到通知后可以去服務(wù)器獲取數(shù)據(jù)信息

1.2.2.負(fù)載均衡
步驟：
1、首先DB在啟動的時候先把自己在ZK上注冊成一個臨時節(jié)點，ZK的節(jié)點后面我們會講到有兩種，一種是永久節(jié)點，一類是臨時節(jié)點臨時節(jié)點在服務(wù)器出現(xiàn)問題的時候，節(jié)點會自動的從ZK上刪除，那么這樣ZK上的服務(wù)器列表就是最新的可用的列表
2、客戶端在需要讀寫數(shù)據(jù)庫的時候首先它去ZooKeeper得到所有可用的DB的連接信息（一張列表）
3、客戶端隨機(jī)選擇一個與之建立連接
4、當(dāng)客戶端發(fā)現(xiàn)連接不可用的時候可再次從ZK上獲取可用的DB連接信息，當(dāng)然也可以在剛獲取的那個列表里移除掉不可用的連接后再隨機(jī)選擇一個DB與之連接

1.2.3.命名服務(wù)
顧名思義，就是提供名稱的服務(wù)，例如數(shù)據(jù)庫表格ID，一般用得比較多的有兩種ID，一種是自動增長的ID，一種是UUID(9291d71a-0354-4d8e-acd8-64f7393c64ae)，兩種ID各自都有缺陷，自動增長的ID局限在單庫單表中使用，不能在分布式中使用，UUID可以在分布式中使用但是由于ID沒有規(guī)律難于理解，我們可以借用ZK來生成一個順序增長的，可以在集群環(huán)境下使用的，命名易于理解的ID

1.2.4.分布式協(xié)調(diào)/通知

心跳檢測
在分布式系統(tǒng)中，我們常常需要知道某個機(jī)器是否可用，傳統(tǒng)的開發(fā)中，可以通過Ping某個主機(jī)來實現(xiàn)，Ping得通說明對方是可用的，相反是不可用的，ZK 中我們讓所有的機(jī)其都注冊一個臨時節(jié)點，我們判斷一個機(jī)器是否可用，我們只需要判斷這個節(jié)點在ZK中是否存在就可以了，不需要直接去連接需要檢查的機(jī)器，降低系統(tǒng)的復(fù)雜度

1.3 zookeeper的優(yōu)勢

1、源代碼開放
2、已經(jīng)被證實是高性能，易用穩(wěn)定的工業(yè)級產(chǎn)品
3、有著廣泛的應(yīng)用：Hadoop,HBase,Storm,Solr

2.Zookeeper中的基本概念

2.1 集群角色

Leader，F(xiàn)ollower，Observer

Leader服務(wù)器是整個Zookeeper集群工作機(jī)制中的核心
Follower服務(wù)器是Zookeeper集群狀態(tài)的跟隨者
Observer服務(wù)器充當(dāng)一個觀察者的角色

Leader，F(xiàn)ollower 設(shè)計模式
Observer 觀察者設(shè)計模式

2.2 會話

會話是指客戶端和ZooKeeper服務(wù)器的連接，ZooKeeper中的會話叫Session，客戶端靠與服務(wù)器建立一個TCP的長連接
來維持一個Session,客戶端在啟動的時候首先會與服務(wù)器建立一個TCP連接，通過這個連接，客戶端能夠通過心跳檢測與服務(wù)器保持有效的會話，也能向ZK服務(wù)器發(fā)送請求并獲得響應(yīng)

2.3 數(shù)據(jù)節(jié)點

Zookeeper中的節(jié)點有兩類
1.集群中的一臺機(jī)器稱為一個節(jié)點
2.數(shù)據(jù)模型中的數(shù)據(jù)單元Znode，分為持久節(jié)點和臨時節(jié)點
Zookeeper的數(shù)據(jù)模型是一棵樹,樹的節(jié)點就是Znode，Znode中可以保存信息

2.4 版本

版本類型說明
version當(dāng)前數(shù)據(jù)節(jié)點數(shù)據(jù)內(nèi)容的版本號
cversion當(dāng)前數(shù)據(jù)節(jié)點子節(jié)點的版本號
aversion當(dāng)前數(shù)據(jù)節(jié)點ACL變更版本號

悲觀鎖和樂觀鎖
悲觀鎖又叫悲觀并發(fā)鎖，是數(shù)據(jù)庫中一種非常嚴(yán)格的鎖策略，具有強(qiáng)烈的排他性，能夠避免不同事務(wù)對同一數(shù)據(jù)并發(fā)更新造成的數(shù)據(jù)不一致性，在上一個事務(wù)沒有完成之前，下一個事務(wù)不能訪問相同的資源，適合數(shù)據(jù)更新競爭非常激烈的場景
相比悲觀鎖，樂觀鎖使用的場景會更多，悲觀鎖認(rèn)為事務(wù)訪問相同數(shù)據(jù)的時候一定會出現(xiàn)相互的干擾，所以簡單粗暴的使用排他訪問的方式，而樂觀鎖認(rèn)為不同事務(wù)訪問相同資源是很少出現(xiàn)相互干擾的情況，因此在事務(wù)處理期間不需要進(jìn)行并發(fā)控制，當(dāng)然樂觀鎖也是鎖，它還是會有并發(fā)的控制！對于數(shù)據(jù)庫我們通常的做法是在每個表中增加一個version版本字段，事務(wù)修改數(shù)據(jù)之前先讀出數(shù)據(jù)，當(dāng)然版號也順勢讀取出來，然后把這個讀取出來的版本號加入到更新語句的條件中，比如，讀取出來的版本號是1,我們修改數(shù)據(jù)的語句可以這樣寫，update 某某表 set 字段一=某某值 where id=1 and version=1，那如果更新失敗了說明以后其他事務(wù)已經(jīng)修改過數(shù)據(jù)了，那系統(tǒng)需要拋出異常給客戶端，讓客戶端自行處理，客戶端可以選擇重試

2.5 watcher

事件監(jiān)聽器
ZooKeeper允許用戶在指定節(jié)點上注冊一些Watcher，當(dāng)數(shù)據(jù)節(jié)點發(fā)生變化的時候，ZooKeeper服務(wù)器會把這個變化的通知發(fā)送給感興趣的客戶端

2.6 ACL權(quán)限控制

ACL是Access Control Lists 的簡寫， ZooKeeper采用ACL策略來進(jìn)行權(quán)限控制，有以下權(quán)限：
CREATE:創(chuàng)建子節(jié)點的權(quán)限
READ:獲取節(jié)點數(shù)據(jù)和子節(jié)點列表的權(quán)限
WRITE:更新節(jié)點數(shù)據(jù)的權(quán)限
DELETE:刪除子節(jié)點的權(quán)限
ADMIN:設(shè)置節(jié)點ACL的權(quán)限