zk乾貨

zk是幹什麼的？？？？？

分佈式服務架構，解決統一命名，狀態同步，集羣管理，分佈式應用配置項管理
爲了減輕分佈式應用程序所承擔的協調任務,好比hadoop中多個NameNode節點，怎麼管理與節點間信息同步，Hbase中master與slaver之間狀態同步。

怎麼幹的？？？

既然是爲了減輕協調任務，產生了角色，有老大leader，跟隨的follower，觀察的observer
leader，負責投票的發起和決議，更新系統參數狀態。
follower，參與系統投票，接受返回客戶端的請求
observer，接收寫請求，轉發給leader，不參與投票

爲何要選舉？？？？？

心跳機制：Leader與Follower利用PING來感知對方的是否存活，當Leader沒法相應PING時，將從新發起Leader選舉。即Leader over了。
怎麼樣才能成爲Leader？？？？
成爲Leader的必要條件： Leader要具備最高的zxid；當集羣的規模是n時，集羣中大多數的機器（至少n/2+1）獲得響應並follow選出的Leader。

服務器的選舉狀態，分爲looking，leading，following和observer

looking:尋找leader狀態，處於該狀態須要進入選舉流程
leading:leader狀態，代表當前服務角色爲leader
following:跟隨者狀態，leader已經選舉出，代表當前爲follower角色
observer:觀察者狀態
ZXID（zookeeper transaction id）：每一個改變Zookeeper狀態的操做都會造成一個對應的zxid，並記錄到transaction log中。 這個值越大，表示更新越新
myid：服務器SID，一個數字,經過配置文件配置，惟一
SID：服務器的惟一標識

選舉有兩種狀況，一是服務器啓動的投票，二是運行期間的投票。

服務啓動的投票：
每一個服務器都發送一個投票（SID，ZXID），開始的時候都是選舉本身當Leader，集羣的每一個服務器收到投票後，首先判斷該投票的有效性，如檢查是不是本輪投票、是否來自LOOKING狀態的服務器。針對每一個投票，依據規則與本身的投票進行pk，pk後根據狀況是否更新投票，再發送給其餘機器，

規則：
優先檢查ZXID，較大的優先成爲Leader，
若是ZXID同樣，SID較大的優先成爲Leader，

統計票結果，是否知足要求選舉了Leader，一旦肯定了，每一個服務器都更新本身的狀態，Leader變動爲Leading，Follower變動爲following。

運行期間投票：
當Leader宕機後，餘下的所非Observer的服務器都會將本身的狀態變動爲Looking，而後開啓新的Leader選舉流程，生成新的(SID,ZXID)信息，後續就與氣動同樣了，

選舉實現的核心思想是：首先建立一個 EPHEMERAL 目錄節點，例如「 /election 」。而後。每個 ZooKeeper 服務器在此目錄下建立一個 SEQUENCE| EPHEMERAL 類型的節點，例如「 /election/n_ 」。在 SEQUENCE 標誌下， ZooKeeper 將自動地爲每個 ZooKeeper 服務器分配一個比前一個分配的序號要大的序號。此時建立節點的 ZooKeeper 服務器中擁有最小序號編號的服務器將成爲 Leader 。

在實際的操做中，還須要保障：當 Leader 服務器發生故障的時候，系統可以快速地選出下一個 ZooKeeper 服務器做爲 Leader 。一個簡單的解決方案是，讓全部的 follower 監視 leader 所對應的節點。當 Leader 發生故障時， Leader 所對應的臨時節點將會自動地被刪除，此操做將會觸發全部監視 Leader 的服務器的 watch 。這樣這些服務器將會收到 Leader 故障的消息，並進而進行下一次的 Leader 選舉操做。可是，這種操做將會致使「從衆效應」的發生，尤爲當集羣中服務器衆多而且帶寬延遲比較大的時候，此種狀況更爲明顯。

在 Zookeeper 中，爲了不從衆效應的發生，它是這樣來實現的：每個 follower 對 follower 集羣中對應的比本身節點序號小一號的節點（也就是全部序號比本身小的節點中的序號最大的節點）設置一個 watch 。只有當 follower 所設置的 watch 被觸發的時候，它才進行 Leader 選舉操做，通常狀況下它將成爲集羣中的下一個 Leader 。很明顯，此 Leader 選舉操做的速度是很快的。由於，每一次 Leader 選舉幾乎只涉及單個 follower 的操做。
————————————————————————————————
這個的意思就是：好比一個節點5watch節點4，當4開始有動做的時候5纔開始，而不至於Leader有問題，同時全部的節點都發起投票。
這裏有一個問題就是如何保證這個投票的ZXID？？？？

Paxos算法解決的什麼問題呢，解決的就是保證每一個節點執行相同的操做序列。好吧，這還不簡單，master維護一個全局寫隊列，全部寫操做都必須 放入這個隊列編號，那麼不管咱們寫多少個節點，只要寫操做是按編號來的，就能保證一致性。沒錯，就是這樣，但是若是master掛了呢。
Paxos算法經過投票來對寫操做進行全局編號，同一時刻，只有一個寫操做被批准，同時併發的寫操做要去爭取選票，只有得到過半數選票的寫操做纔會被 批准（因此永遠只會有一個寫操做獲得批准），其餘的寫操做競爭失敗只好再發起一
輪投票，就這樣，在日復一日年復一年的投票中，全部寫操做都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個
編號爲100的寫操做，以後又接受到編號爲99的寫操做（由於網絡延遲等不少不可預見緣由），它立刻能意識到本身 數據不一致了，自動中止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性（總2n+1臺，除非掛掉大於n臺）。

這個是裏邊有幾個zk術語寫的不錯
https://juejin.im/post/5bab525df265da0aa74f2f73

這個總結的知識點多，比較散不繫統，能夠看看
https://youzhixueyuan.com/architecture-design-and-application-scenario-of-zookeeper.html

zk的核心：Zab協議：恢復和廣播，
這個鏈接比較詳細
https://zhuanlan.zhihu.com/p/60352367
zk的watch機制就是實現管理分佈式配置的，https://www.jianshu.com/p/abde992b9060
節點配置信息發生更改，watch管理器就會向客戶端發起回調，實現管理分佈式更新。

zk的監控能夠用淘寶的或者zkui，
zkui安裝須要用到maven環境，若是有bin模式的最好下載bin模式，不要用源碼本身安裝，配置鏈接：https://blog.csdn.net/yy1300326388/article/details/45027775
下載地址；https://maven.apache.org/download.cgi
注意，提早監測javac命令是否存在，
echo stat | nc 127.0.0.1 2181 可能提示命令沒有在whitelist裏邊，須要給zkServer.sh配置一個參數
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"
重啓zkServer.sh restart便可

Zookeeper監控
對於zookeeper的監控，咱們可使用zk提供的4字命令返回的內容進行解析監控
固然，你也可使用淘寶的開源工具TaoKeeper進行監控。Zookeeper的監控包括下面幾個方面：
一、機器的CPU、內存、負載、硬盤IO利用率等基礎監控，這些都可以網管系統實現；
二、ZK日誌目錄所在磁盤空間監控，這能夠針對性的監控；
三、各節點的進程監控，配置自動拉起等；
四、各節點的鏈接數監控，配置峯值告警；
五、各節點的Watcher數監控，配置峯值告警；
六、使用四字命令，對每一個節點進行檢查，確保進程不僵死；
七、節點存活個數監控；

zk幾個實際的應用及優化建議案例
https://data.qq.com/article?id=2863