Zookeeper 協(xié)議

簡(jiǎn)介：分布式協(xié)調(diào)服務(wù)，提供諸如統(tǒng)一命名、配置管理等基礎(chǔ)服務(wù)
越來(lái)越多的分布式應(yīng)用面臨數(shù)據(jù)一致性問(wèn)題，Zookeeper的設(shè)計(jì)目標(biāo)是將那些復(fù)雜且容易出錯(cuò)的分布式一致服務(wù)封裝起來(lái)，構(gòu)建一個(gè)高效可靠的原語(yǔ)集，并以一系列簡(jiǎn)單可用的接口提供給用戶使用

設(shè)計(jì)目標(biāo)：

• 簡(jiǎn)單的數(shù)據(jù)模型
• 可構(gòu)建集群
• 順序訪問(wèn)
• 高性能

基礎(chǔ)概念：

• 集群
• 會(huì)話
• Znode
• 版本
• Watcher
• ACL create read write delete admin

Zookeeper簡(jiǎn)單應(yīng)用場(chǎng)景

• redis 服務(wù)發(fā)現(xiàn)和治理
  在redis實(shí)際應(yīng)用中，一般會(huì)有一個(gè)主節(jié)點(diǎn)redis，幾個(gè)從屬節(jié)點(diǎn)redis。
  主節(jié)點(diǎn)處理用戶寫請(qǐng)求，從節(jié)點(diǎn)向主節(jié)點(diǎn)同步數(shù)據(jù)，處理用戶讀的請(qǐng)求。

當(dāng)主節(jié)點(diǎn)故障的時(shí)候，從節(jié)點(diǎn)會(huì)通過(guò)raft算法選舉出新的主節(jié)點(diǎn)處理用戶寫請(qǐng)求。

問(wèn)題產(chǎn)生:如何在主服務(wù)器變更后，更新項(xiàng)目redis讀寫配置？

原始做法: 修改項(xiàng)目代碼里面的redis地址和端口，然后上傳代碼，再重新部署

Zookeeper解決方法:通過(guò)zookeeper監(jiān)控主從服務(wù)器變動(dòng)，在項(xiàng)目里面引入zookeeper客戶端，當(dāng)主服務(wù)器變更的時(shí)候，zookeeper客戶端會(huì)收到通知，在通知回調(diào)里，我們可以收到新的主節(jié)點(diǎn)地址和端口，根據(jù)他寫一段redis重啟代碼，這樣就避免了服務(wù)器重啟

Zookeeper 使用和API

創(chuàng)建 create(final String path, byte data, List<ACL> acl, CraeteMode createMode)
讀取 getChildren(path, watcher, watch, cb, ctx, stat) getData(path, watcher, stat, watch, cb, ctx)
更新 setData(path, data, version)
刪除 delete (path ,version)
判斷節(jié)點(diǎn)是否存在 exists(path, watcher)

ZAB協(xié)議

ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)Zookeeper專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議
ZAB不像Paxos算法那樣是一種通用的分布式一直算法，他是一種特別為Zookeeper設(shè)計(jì)的崩潰可恢復(fù)的原子廣播算法

• 主備模式，單一主進(jìn)程處理事務(wù)
• 全局的變更時(shí)序，也就是說(shuō)如果一個(gè)狀態(tài)更新已經(jīng)發(fā)生了，那么所有其依賴的狀態(tài)變更都應(yīng)該被提前處理了
• 支持崩潰恢復(fù)

Zookeeper兩種基本模式，崩潰恢復(fù)和消息廣播，還有一種數(shù)據(jù)恢復(fù)模式
Leader服務(wù)器收到事務(wù)，轉(zhuǎn)化成Proposal，F(xiàn)ollow服務(wù)器收到事務(wù)，轉(zhuǎn)發(fā)給Leader

消息廣播

類似二階段提交
區(qū)別在于移除了中斷邏輯，所有的Follower要么正常反饋Leader提出的事務(wù)Proposal，要么拋棄Leader服務(wù)器。所以這意味著

• Leader收到過(guò)半的Ack就可以Commit了，不需要等所有的回復(fù)
• 無(wú)法處理Leader奔潰退出帶來(lái)的數(shù)據(jù)不一致

基于TCP協(xié)議，可以做到FIFO
Leader會(huì)為每個(gè)Proposal分配一個(gè)ZXID

Leader為每一個(gè)Follower保存一個(gè)隊(duì)列，發(fā)送Proposal，然后Follow保存事務(wù)日志到磁盤，然后回復(fù)ACK，Leader收到過(guò)半ACK后廣播Commit，然后Follow提交Commit

崩潰恢復(fù)

ZAB保證如果一個(gè)事務(wù)的Proposal在一臺(tái)機(jī)器上被處理成功，那么應(yīng)該在所有的機(jī)器上都處理成功，兩種特征

• ZAB協(xié)議需要確保已經(jīng)在Leader服務(wù)器上確認(rèn)的事務(wù)最終被所有的服務(wù)器都提交
• ZAB協(xié)議需要確保丟棄那些只在Leader服務(wù)器上被提出的事務(wù)

誰(shuí)是Leader：讓所有機(jī)器中擁有最高的Proposal ZXID的Follower做Leader
步驟分成三步：發(fā)現(xiàn)、同步、廣播

• 步驟 F.1.1 Follower F 將自己最后接受的事務(wù)Proposal的epoch值CEPOCH(Fp)發(fā)送給準(zhǔn)Leader L
• 步驟 L.1.1 當(dāng)接受到來(lái)自過(guò)半Follower發(fā)送的CEPOCH值后，準(zhǔn)Leader發(fā)送NEWEPOCH(e’)給過(guò)半的Follower
• 步驟 F.1.2 賦值并且發(fā)送ACK（當(dāng)前Follower的事務(wù)集合）
• Leader選出一個(gè)覆蓋最全面的Proposal組合

同步階段

• 將最全面的Proposal組合同步給所有的Follower
  廣播階段

e為主進(jìn)程序列號(hào)也是主進(jìn)程周期

Zookeeper 應(yīng)用場(chǎng)景

數(shù)據(jù)發(fā)布、訂閱

• 實(shí)現(xiàn)配置信息的集中式管理和數(shù)據(jù)的動(dòng)態(tài)更新
• 應(yīng)用：數(shù)據(jù)庫(kù)、機(jī)器列表、選項(xiàng)開關(guān)
  負(fù)載均衡 DDNS
• 本地host
• 全自動(dòng)的dns，消費(fèi)者和服務(wù)者、注冊(cè)中心、檢測(cè)中心
  命名服務(wù)
• 全局唯一ID，mysq auto increment 單機(jī)有效，UUID太長(zhǎng)、含義不明
• 用創(chuàng)建順序節(jié)點(diǎn)的方式實(shí)現(xiàn)
  分布式協(xié)調(diào)通知
• 任務(wù)調(diào)度
  Master選舉
  分布式鎖
  分布式隊(duì)列

在我們系統(tǒng)中的應(yīng)用

數(shù)據(jù)庫(kù)等信息的配置
服務(wù)地址的配置
分布式鎖