0. Chubby 協(xié)議

• 面向松耦合分布式系統(tǒng)的鎖服務(wù), 解決分布式中的一致性問題.

• 鎖服務(wù):
  • 粗粒度的鎖服務(wù): 客戶端會(huì)長(zhǎng)時(shí)間持有鎖.
  • 鎖在分布式系統(tǒng)中的用途:
    • 允許客戶端進(jìn)程同步彼此的操作, 并對(duì)當(dāng)前所處環(huán)境的基本信息達(dá)成一致.
• 通過"文件"實(shí)現(xiàn)鎖:
  • 首先, Chubby 是一個(gè)分布式文件系統(tǒng), 對(duì)其而言: 鎖就是文件.
  • 創(chuàng)建文件就是進(jìn)行"加鎖"操作, 而成功創(chuàng)建文件的服務(wù)器就搶占到了"鎖".
  • 用戶通過打開, 關(guān)閉, 讀取文件獲取共享鎖或者獨(dú)占鎖.
  • 文件有更新時(shí), 會(huì)通知相關(guān)的用戶.

• 系統(tǒng)架構(gòu)圖

  
  
  • 分為兩個(gè)部分: 服務(wù)器稱為Chubby cell；?每個(gè)client都有一個(gè)Chubby library寥粹。
    • 兩端使用RPC 進(jìn)行通信.
    • 客戶端通過Chubby library 的接口調(diào)用, 在 Chubby cell 上創(chuàng)建文件來獲取鎖.
• 優(yōu)勢(shì)
  • 開發(fā)人員對(duì)基于鎖的接口更為熟悉, 遠(yuǎn)比一致性協(xié)議的庫更為友好.
  • 對(duì)上層應(yīng)用程序的侵入性更小, 易于保持系統(tǒng)已有的程序結(jié)構(gòu)和網(wǎng)絡(luò)通信模式.
  • 便于提供數(shù)據(jù)的發(fā)布與訂閱, 以讓客戶端實(shí)時(shí)地感知到Master 的變化.
  • 允許客戶端在?服務(wù)器上進(jìn)行小文件的讀寫操作.
  • 更便捷地構(gòu)建更可靠的服務(wù). 需要Quorum 機(jī)制進(jìn)行數(shù)據(jù)項(xiàng)值的選定.
• Master 服務(wù)器
  • master lease
    • mater在運(yùn)行過程中,不斷續(xù)租來延長(zhǎng)lease.
  • 客戶端向記錄有服務(wù)器機(jī)器列表的DNS來請(qǐng)求所有的服務(wù)器,然后逐個(gè)詢問是否為Master
    • 非Master會(huì)將當(dāng)前Master表示回饋給客戶端, 達(dá)到了非常快的定位.
  • 若集群中服務(wù)器崩潰且無法恢復(fù), 則需要加入新機(jī)器, 并更新DNS 列表(啟動(dòng)服務(wù)端程序,更新DNS 上的機(jī)器列表).
    • Master會(huì)周期性輪訓(xùn)DNS 列表, 并很快感知到服務(wù)器地址的變更, 然后通知集群.

1. Ensemble

為了達(dá)到高可用性, 會(huì)同時(shí)運(yùn)行多個(gè)Zookeeper 服務(wù)器, 稱為ensemble.

zookeeper_ensemble.png

• 復(fù)制服務(wù).
  • 需要服務(wù)器集中中大多數(shù)機(jī)器正常工作, 才能提供服務(wù).
  • 崩潰掉的服務(wù)器, 可以使用crash-recovery 協(xié)議來恢復(fù)并重新進(jìn)入到ensemble.
• primary 服務(wù)器接收并執(zhí)行所有的請(qǐng)求, 然后傳播執(zhí)行結(jié)果.
  • 當(dāng)primary 崩潰掉后, 執(zhí)行恢復(fù)協(xié)議來統(tǒng)一一致性狀態(tài), 并建立新的primary.
  • 所有讀操作都是in-memory 的, 擁有很高的速度.
• 每個(gè)服務(wù)器會(huì)在內(nèi)存中維持一個(gè)(代表ensemble 節(jié)點(diǎn)組成的)分布式文件系統(tǒng)的副本.
• 每個(gè)client 一個(gè)到服務(wù)器的session. 并由ensemble 提供以下特性:
  • 自動(dòng)且透明化的故障轉(zhuǎn)移.
  • 自動(dòng)化的keep-alive.
  • 客戶請(qǐng)求超時(shí).

2. 數(shù)據(jù)一致性

• 最終一致性(Eventual Consistency)
  • followers may lag(遲于) leader.
• 順序的一致性(Sequential Consistency)
  • 客戶端的更新請(qǐng)求, 會(huì)以請(qǐng)求發(fā)送的順序來被應(yīng)用.

3. ?節(jié)點(diǎn)

• 臨時(shí)的(Ephemeral)節(jié)點(diǎn)
  • 會(huì)話過期時(shí)消亡.
  • 由其生命周期決定, 并不會(huì)有子節(jié)點(diǎn).
  • 使用場(chǎng)景: 組成員, leader 選舉.
• 持久化的(Persistent)節(jié)點(diǎn)可以含有子節(jié)點(diǎn), 類似于目錄.
• 節(jié)點(diǎn)的用途:
  • 節(jié)點(diǎn)可以持有(小于1M的)數(shù)據(jù), 類似于文件.
  • 提供像 創(chuàng)建,刪除, 檢查存在性的基本節(jié)點(diǎn)操作.
• 由節(jié)點(diǎn)構(gòu)成Group Membership
  • 提供事件驅(qū)動(dòng)模型, 客戶端可以監(jiān)聽特定節(jié)點(diǎn)的變化.
  • 對(duì)外暴露的是文件系統(tǒng)模型, 有層級(jí)的命名空間.

4. Replication

• 復(fù)制是以軟件手段來增加數(shù)據(jù)的可用性.

• 常用于數(shù)據(jù)庫和分布式系統(tǒng)中, 提供合理的性能, 并維持?jǐn)?shù)據(jù)一致性.
• 在數(shù)據(jù)庫中,使用延遲(deferred)更新模型.
  • 事務(wù)由本地的服務(wù)器(replica manager)處理, 并在提交時(shí), 轉(zhuǎn)發(fā)給其它服務(wù)器.
  • 與之相對(duì)的是立即更新模型, 它會(huì)在所有的服務(wù)器間同步事務(wù).

• 復(fù)制數(shù)據(jù)庫模型

  
  
  • 由一系列運(yùn)行在不同處理器上的process 組成.
  • 每個(gè)process 都有數(shù)據(jù)庫的一個(gè)副本, 被稱為replica manager.
  • 每個(gè)process 有兩種狀態(tài): Up && Down.

• 終止協(xié)議(Termination Protocol).

  
  
  • 向其它process 提交事務(wù), 并確認(rèn)該動(dòng)作.
  • 在CS 分布式系統(tǒng)中, 使用原子廣播(atomic broadcast).
  • 可以向多個(gè)process 發(fā)送同一消息, 并且保證消息順序?yàn)榘l(fā)送順序.
  • certifier 向Data Manager 詢問已提交事務(wù)的信息, 如果該事務(wù)已經(jīng)被驗(yàn)證通過, 它的寫操作會(huì)被提交給Lock Manager.

5. Zookeeper 的典型應(yīng)用場(chǎng)景

5.1 配置中心: 數(shù)據(jù)的發(fā)布/訂閱

• 推拉結(jié)合的方式:
  • 客戶端注冊(cè)的關(guān)注節(jié)點(diǎn)發(fā)送數(shù)據(jù)變更時(shí), 會(huì)向客戶端發(fā)送watch 事件通知.
  • 客戶端在接收到通知后, 需要主動(dòng)向服務(wù)索取最新數(shù)據(jù).
• 將配置信息放到Zookeeper上進(jìn)行集中管理,
  • 應(yīng)用在啟動(dòng)時(shí)主動(dòng)向Zookeeper 服務(wù)器索取配置, 同時(shí)監(jiān)聽配置的變化.
  • 典型場(chǎng)景: 全局配置信息
    • 包含: 機(jī)器列表, 運(yùn)行時(shí)開關(guān)配置, 數(shù)據(jù)庫配置.
    • 特性: 數(shù)據(jù)量小; 運(yùn)行時(shí)動(dòng)態(tài)變化; 各機(jī)器共享; 配置一致.

5.2 負(fù)載均衡

• 動(dòng)態(tài)DNS服務(wù). 超大規(guī)模的分布式(域名到IP的)映射表.
  • 使用本地host 綁定可以實(shí)現(xiàn)域名解析.
    • 但是當(dāng)主機(jī)規(guī)模龐大, 或需要更新域名時(shí),有致命缺陷.
  • Dynamic DNS. 創(chuàng)建一個(gè)節(jié)點(diǎn)進(jìn)行域名配置.
    • 域名解析過程?需要每個(gè)應(yīng)用自己負(fù)責(zé).

5.3 命名服務(wù).

• 資源定位不是真正的實(shí)體資源.
• 分布式全局唯一ID的分配機(jī)制.
  • UUID的缺陷:長(zhǎng)度過長(zhǎng),含義不明.
• 通過調(diào)用Zookeeper節(jié)點(diǎn)創(chuàng)建API可以創(chuàng)建順序節(jié)點(diǎn), 并在API返回值中會(huì)返回這個(gè)節(jié)點(diǎn)的完整名字.
  • 創(chuàng)建順序子節(jié)點(diǎn)時(shí), 自動(dòng)以后綴形式在子節(jié)點(diǎn)上添加序號(hào).

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

• MySQL數(shù)據(jù)復(fù)制總線. Mysql_Replicator.
  • 在不同MySQL 實(shí)例間進(jìn)行異步數(shù)據(jù)復(fù)制和數(shù)據(jù)變化通知.
  • 讓不同的機(jī)器都在Zookeeper 的?指定節(jié)點(diǎn)下創(chuàng)建臨時(shí)節(jié)點(diǎn), 不同機(jī)器間根據(jù)這個(gè)臨時(shí)節(jié)點(diǎn)判斷對(duì)應(yīng)的客戶端機(jī)器是否存活.
    • 解耦了檢測(cè)和被檢測(cè)系統(tǒng).
    • 同時(shí)可實(shí)時(shí)地將自己任務(wù)執(zhí)行進(jìn)度寫入臨時(shí)節(jié)點(diǎn).

5.5 集群管理

• 集群監(jiān)控(運(yùn)行時(shí)狀態(tài)的收集)和集群控制(上下線操作).
• 基于Agent 體系的集群管理:
  • 每臺(tái)機(jī)器上的Agent 主動(dòng)向指定的監(jiān)控中心系統(tǒng)匯報(bào)狀態(tài).
  • 當(dāng)集群規(guī)模變大后會(huì)造成問題:
    • 大規(guī)模升級(jí)困難; 統(tǒng)一的agent無法滿足定制需求; 編程語言多樣性.
• 特性:
  • 當(dāng)客戶端對(duì)數(shù)據(jù)節(jié)點(diǎn)注冊(cè)watcher 監(jiān)聽后, 當(dāng)數(shù)據(jù)節(jié)點(diǎn)的內(nèi)容或子節(jié)點(diǎn)列表發(fā)生變更時(shí),會(huì)收到通知.
  • 臨時(shí)節(jié)點(diǎn)會(huì)在客戶端與服務(wù)器的會(huì)話失效后,被自動(dòng)清除.
• 分布式日志收集系統(tǒng).
  • 把所有需要收集的日志機(jī)器分為多個(gè)組, 每個(gè)組對(duì)應(yīng)一個(gè)后臺(tái)機(jī)器作為收集器.
  • ?特性: 變化的日志源機(jī)器, 變化的收集器機(jī)器.?達(dá)到了快速合理動(dòng)態(tài)地為每個(gè)收集器分配對(duì)應(yīng)的日志源機(jī)器..