liunx篇】 十三. zookeeper介紹，常用命令，應用場景和集羣

中國加油，武漢加油！

篇幅較長，配合目錄觀看

案例準備

1. 裝了zookeeper的Centos7的虛擬機或者服務器

1. zookeeper介紹

1. ZooKeeper是一個分佈式服務框架，是Apache Hadoop 的一個子項目，它主要是用來解決分佈式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集羣管理、分佈式應用配置項的管理等。
2. 簡單來說zookeeper=文件系統+監聽通知機制。
3. ZooKeeper最爲主要的使用場景，是作爲分佈式系統的分佈式協同服務。
4. 在學習zookeeper之前，先要對分佈式系統的概念有所瞭解。
   

2. zookeeper樹形結構

每個子目錄項如 NameService 都被稱作爲 znode(目錄節點)，和文件系統一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，唯一的不同在於znode是可以存儲數據的。

2.1 znode類型

節點	描述
ERSISTENT	持久化目錄節點，客戶端與zookeeper斷開連接後，該節點依舊存在
PERSISTENT_SEQUENTIAL	持久化順序編號目錄節點，客戶端與zookeeper斷開連接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
EPHEMERAL	臨時目錄節點，客戶端與zookeeper斷開連接後，該節點被刪除
EPHEMERAL_SEQUENTIAL	臨時順序編號目錄節點，客戶端與zookeeper斷開連接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

3. zookeeper常用命令

節點	描述
ls path	顯示節點下的子節點
create [-s] [-e] path	創建節點 [-s] 順序節點，[-e] 臨時性節點
get path	獲取節點內容
set path value	設置節點的內容
delete path	刪除節點

4. zookeeper監聽通知機制（watch）

1. zookeeper提供了節點watch的功能，zookeeper的client監控zookeeper上的節點，當節點變動的時候，client會收到變動事件和變動後的內容。
2. 基於zookeeper的這個特性，我們可以給服務器集羣中的所有機器都註冊watch事件，監控特定znode，節點中存儲部署代碼的配置信息，需要更新代碼的時候，修改znode中的值，服務器集羣中的每一臺server都會收到代碼更新事件，然後觸發調用，更新目標代碼。
3. 也可以很容易的橫向擴展，可以隨意的增刪機器，機器啓動的時候註冊監控節點事件即可。
   

5. zookeeper應用場景

5.1 配置文件管理

1. 程序通常會需要進行一些配置文件進行配置的管理。但是如果對於分佈式項目來說，可能會部署在不同的服務器上，這樣每臺服務都會有自己的一套配置，如果需要對某些配置進行調整，則需要逐一的對各個服務器進行修改。zookeeper能夠實現統一的配置文件管理。
2. 將需要統一管理的配置全部放到zookeeper上去，保存在 zookeeper 的某個目錄節點中，然後所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 zookeeper的通知，然後從 zookeeper獲取新的配置信息應用到系統中。
   

5.2 集羣管理

1. 所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然後監聽父目錄節點的子節點變化消息。
2. 一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除。新機器加入也是類似，
3. 我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作爲master就好。

5.3 分佈式鎖

1. 我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。
2. 所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。
3. 用完刪除掉自己創建的distribute_lock 節點就釋放出鎖

5.4 命名服務(Dubbo監控中心原理)

1. 在日常開發中，我們會遇到這樣的場景：服務A需要訪問服務B，但是服務B還在開發過程中（未完成），那麼服務A（此時已完成）就不知道如何獲取服務B的訪問路徑了，使用zookeeper的服務就可以簡單解決。
2. 服務B部署成功後，可以先到zookeeper註冊服務（即在zookeeper添加節點/service/B和節點數據）。
3. 服務A開發結束後，部署到服務器，然後服務A監控zookeeper服務節點/service/B。
4. 如果發現節點有數據了，那麼服務A就可以訪問服務B了。

5.5 發現服務

1. 註冊一個持久節點/service/business/what，他下面的每個子節點都是一個可用服務，保存了服務的地址端口等信息。
2. 服務調用者通過zookeeper獲取/service/business/what所有子節點信息來得到可用的服務。下面的節點都是臨時節點，服務器啓動的時候會過來註冊一個臨時節點，服務器掛掉之後或主動關閉之後，臨時節點會自動移除。
3. 這樣就可以保證使用者獲取的what服務都是可用的，而且可以動態的擴容縮容。
   

6. zookeeper集羣

1. zookeeper集羣存在兩個角色，一個是Leader其他都是Follower。
2. 一個zookeeper集羣同一時刻只會有一個 Leader，其他都是 Follower。
3. Leader 負責數據的讀寫，而Follower只負責數據的讀，如果Follower遇到寫操作，會提交到Leader。
4. ZooKeeper 集羣的所有機器通過一個 Leader 選舉過程來選定一臺被稱爲『Leader』 的機器，Leader服務器爲客戶端提供讀和寫服務。Follower只提供讀服務，不能提供寫服務。
   4.1. 如果有機器要對節點做更新，這個機器先告訴Leader。
   4.2. Leader收到後廣播給所有的節點進行寫操作，每個角色都在自己的機器中寫。
   4.3. 每個機器寫完後都給Leader彙報是否寫入成功
   4.4. 如果有一半的機器寫成功了Leader就下發第二個指令
   4.5. 廣播提交事務

6.1 Leader選舉

1. 所有節點都有兩個屬性，sid和zxid。
2. 選舉的目的就是選目前所有節點中擁有最大zxid的節點作爲Leader。
3. 如果擁有的zxid相同，就選取sid最大的節點作爲Leader，其他節點變爲Follower。
4. zxid：服務器中存放的最大數據ID,值越大說明數據越新，在選舉算法中數據越新權重越大，每次數據變動都會自增。
5. sid：該投票信息所屬的serverId（比如有三臺服務器，編號分別是1，2，3）。

6.2 過半數存活原則

1. 在zookeeper集羣中,當存活的機器數量超過總機器的一半的時候,整個集羣才能正常工作,否則拒絕訪問。
2. 基於過半數存活原則,zookeeper的集羣機器數量一定是奇數臺。
3. 因爲2N+1和2N+2的容災能力是一樣的,基於成本考慮2N+1臺的選擇方案更優。

6.3 爲什麼zookeeper需要設計一個過半數存活機制?

1. 腦裂問題：集羣中的節點監聽不到leader節點的心跳, 就會認爲leader節點出了問題，此時集羣將分裂爲不同的小集羣, 這些小集羣會各自選舉出自己的leader節點, 導致原有的集羣中出現多個leader節點。
2. 爲了防止網絡腦裂,保證數據的強一致性，因爲整個集羣中,有可能因爲網絡問題"腦裂",導致整個集羣分爲2個甚至多個集羣。
3. 如果沒有過半數存活機制,那麼整個zookeeper會變成多個集羣,那麼zookeeper提供的數據無法再保證數據一致性;