一、介紹

　　一個分布式協調服務框架；

　　一個精簡的文件系統，每個節點大小最好不大于1MB；

　　眾多hadoop組件依賴于此，比如hdfs，kafka，hbase，storm等；

　　旨在，分布式應用中，提供一個可靠的、可拓展的、分布式的、可配置的協調機制來管理整個集群的狀態；

　　主要角色有：leader、follower、observer。

二、簡單使用配置

　　安裝很簡單。一個tar包解壓即可。

　　啟動所需的配置文件為：zk安裝目錄/conf/zoo.cfg（需將安裝包中原zoo_sample.cfg改名為zoo.cfg）

　　配置文件中，需指定dataDir,這個參數可以自定義，其意義為存放zk集群環境配置信息的。

　　clientport為客戶端連接zk端口，默認為2181

　　此外，分布式集群zk，需增加配置，指定集群中每一個節點的ip。

　　因為我用的是3.4.7版本，集群中本機ip必須指定為0.0.0.0。

　　此外，還需要在指定的dataDir的數據目錄下，創建一個myid文件，此中只需要寫本zk的id。

　　我這里的集群是3臺zk。每臺配置基本都是如此，其他都是默認配置。

　　啟動命令：./zkServer.sh start ----->>>觀察zk狀態:./zkServer.sh status可以觀察當前zk服務狀態，啟動會顯示zk的角色。

　　啟動zk客戶端可以進行一些簡單對于zk的操作：./zkCli.sh

三、基本運行原理

　　1、zk結構

　　　　

　　1）zk有一個根節點------>>>"/"；

　　2）每個節點都叫znode節點；

　　3）每個znode都會有自己的子節點；

　　4）每個子節點的路徑都是唯一的；

　　5）不可用zk節點存儲海量數據，第一與其使用場景不符合，第二zk對節點的存儲基于內存，容易撐爆內存，且多臺zk存儲的屬于都一致；

　　6）zk持久化目錄就在于傳說中的，配置文件中指定的dataDir目錄；

　　7）zk回為每一個操作，除讀之外的，分配一個全局遞增的事務id；

　　8）zk可以創建臨時順序節點，基于此，主節點服務器可以對應一個臨時節點，備用服務器監控此臨時節點，當主節點掛了時，此備用節點也會消失，從而備用節點可以頂上，從而zk可以管理集群中節點的服務狀態。

?

?　　2、zk選舉

　　zk本身是支持HA的，在集群中會存在一個leader，其他都是follower，leader和follower之間會存在心跳訪問，當leader掛了之后，zk集群接下一步的操作為重新選舉新的leader；

　　1）如果并非leader掛了的情況，而是新啟動zk集群，那么zk集群會先從本地指定的dataDir中恢復本節點數據，找到本方最大的事務id，即是最新的事務，此階段為數據恢復階段；

　　2）選舉過程，集群中的每臺zk都會向彼此提交選舉協議，希望成為leader；

　　　　選舉協議中包含本節點最新的事務id，自己在集群中的id，邏輯時鐘值（確保是在同一輪選舉中）；

　　　　這時候zk節點會多出一個狀態為looking狀態；

　　3）PK原則，先比較事務id，誰的事務id最大誰是leader；

　　　　如果zxid比較不出，那就比選舉id，此時需滿足過半性原則，01、02、03為02，01、03、02為03，02、03，01為03，03、02、01為03

　　　　簡單總結，進行id比較，從先向后啟動順序比較，誰滿足了一半同意，誰就是leader。

?　　　　zk的選舉機制可以保證崩潰恢復，當leader掛了之后，如果集群數量滿足過半性，那么就會從剩下的follower中選出薪的leader。

　　3、zk分布式一致性算法

?　　先了解分布式一致性算法有哪些：

　　2PC算法-------->>>二階段提交算法：

　　階段一：leader向follower詢問是否可以進行事務提交操作，follower進行預執行，如果都成功，先不提交，返回成功ack給leader;

　　階段二：若所有follower都是成功ack，那么leader通知所有follower進行事務提交操作，事務完成；

　　　　　　若有follower有返回失敗ack或者超時響應，leader通知所有follower進行回滾操作，follower給leader返回回滾ack。事務失敗。

?　　優點是簡單，方便實現。

　　缺點是同步阻塞，leader在1階段后一致在等待，造成時間浪費；

　　leader會存在單點問題，事務中leader掛了的話，那么整個事務將無法繼續運行。

?　　ZK使用的是改進后Paxos算法，也是改進后的二階段提交算法：ZAB協議：

　　1）進行消息原子廣播，保證數據一致性；

　　2）崩潰恢復，解決了2PC算法的單點問題。

　　簡單說明ZAB協議：

　　1）zk通過原子（消息）廣播的方式進行通信；

　　2）zk有一個單一的leader接收并處理所有client的事務請求，然后將數據狀態的更新，通過廣播的方式通知到所有的follower或者Observer中；

　　3）每一個事務請求都有一個全局唯一的id，此id為zxid，遞增；

　　4）通過消息的廣播的方式，每個follower接收到事務請求后，處理事務后，返回ack，只要follower收到半數以上的成功ack事務即成功。

　　但說到這里，并未解決leader的單點問題，并且只是半數ack即確認事務成功，雖然提高了效率，但是事務一致性可疑；

　　所以，zk更加詳細的ZAB協議應該為：

　　1）leader將所有的事務分配一個遞增的全局事務id；

　　2）leader在進行原子廣播事務操作時，為每一個follower單獨創建一個propersal（提案）隊列，隊列遵循fifo的策略，將事務操作放入，然后原子廣播出去；

　　3）follower也有一個先入先出的事務隊列，收到事務操作后，將事務操作寫入事務日志中，然后反饋給leader，ack，leader收到半數以上的follower的ack后，會再次發出原子廣播指揮所有的follower進行事務提交操作；

　　這個時候，假如有的follower沒有返回ack，但是收到了commit指令，那么將直接執行完事務后提交事務；

　　如果這個follower掛掉了，那么當他重啟時會進入數據恢復階段，與follower進行數據一致性的同步，由這一點可見過半性原則的重要性；

　　當leader掛了之后，進入到崩潰恢復階段；

　　1）整個zk集群假如仍有半數以上活著，先進行leader的選舉操作；

　　2）如果所有的follower事務id都是一致的，從來沒有接受過之前的事務操作，那么此事務就當沒執行過，飄到外星宇宙去了（因為leader極端的在一瞬間進行原子廣播時，失去了所有的follower）；

　　3）那么根據zk的選舉原則，新leader的事務id一定是最新的，對于剛才的事務，要不已經提交，要不未進行提交操作，對于未進行提交操作的，新的leader復制繼續完成此事務，進行事務操作；

　　4）zk集群進入廣播模式，新來的節點進行數據恢復。當原leader恢復了之后，會廢掉自己的porpersal，從而成為follower。

參考：https://www.jianshu.com/p/400a44edee88

?

?

?

?

?

?

?

?

??

?

轉載于:https://www.cnblogs.com/qfxydtk/p/11227436.html

總結

以上是生活随笔為你收集整理的hadoop知识整理（4）之zookeeper的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。