Paxos的工程實踐

Chubby 大名鼎鼎的分佈式鎖算法

  • GFS、Bigtable 都用他來解決分佈式協助問題、元數據存儲、Master選舉等一系列問題
  • 底層一致性實現就是Paxos

Chubby 是一個面向鬆耦合分佈式系統的鎖服務數據庫

  • 提供高可用的分佈式鎖服務
  • 一個分佈式鎖的目的是:
    • 容許客戶端同步彼此的操做,並對當前所處環境的基本狀態信息達成一致
  • 粗粒度鎖服務,不須要使用複雜的同步協議
  • 設計成一個須要訪問中心節點的分佈式鎖服務

分佈式鎖服務具備4個傳統算法庫所不具備的優勢:緩存

  1. 對上層應用程序侵入性更小
    • 在系統用戶達到必定規模前,高可用性並未被足夠重視,
    • 達到必定規模後,開始重視,集羣等措施加上去,一致性變得相當重要
    • 分佈式鎖服務比封裝一致性協議的客戶端庫侵入性小
  2. 便於提供數據的發佈與訂閱
    • 分佈式鎖很是適合提供該功能,兩者實現上是相通的
  3. 開發人員對基於鎖的接口更爲熟悉
    • Chubby 提供了一套近乎和單機鎖機制一致的分佈式鎖服務
    • 遠比一致性協議庫來的更加友好
  4. 更便捷的構建更可靠的服務
    • 分佈式一致性算法,都要用Quorum機制來進行數據項值得選定
    • Quorum機制:指在一個集羣中,一個數據項值得選定須要集羣中過半數機器贊成,只要集羣中3臺機器存在,就能提供正常的服務;
    • 而分佈式一致性協議,只能交給開發人員本身處理,增長了開發成本

Chubby 設計目標:服務器

  1. 提供一個完整的、獨立的分佈式鎖服務,而非一致性協議的客戶庫
  2. 提供粗粒度的鎖服務
    • Chubby 提供的是長時間持有的鎖
  3. 提供鎖服務的同時,提供小文件的讀寫功能
    • 提供小文件的讀寫功能,可使得被選舉出來的Master ,在不依賴額外服務的狀況下,很是方便的向全部客戶端發佈本身的狀態信息。
  4. 高可用高可靠
    • 只要三臺以上就能提供正常服務
    • 支持小文件讀寫服務,進行Master 選舉結果的發佈訂閱
  5. 提供事件通知機制
    • 服務端數據變化,以事件通知的方式實時通知訂閱的客戶端

Chubby 技術架構session

  • Chubby 集羣稱爲 Chubby  cell 一般由5臺服務器組成。
  • 副本服務器經過Paxos 協議,投票產生Master(票數過半)
  • 一旦一臺服務器稱爲Master,Chubby保證一段時間不會再有其餘服務器成爲Master(這段時間叫作「Master租期」)
  • Master 服務器會不斷延長租期的形式續租,一旦故障,從新選舉
  • 每臺服務器都保存服務器數據庫副本,只有Master 能寫,其餘與之保持同步
  • 客戶端如何定位Master
    • 首先向記錄有服務端機器列表的DNS獲取全部Chubby 服務
    • 挨個詢問是不是Master,非Master 會把Master 返回給客戶端
  • 一旦定位到Master ,寫請求會廣播給全部服務器,過半接受了該請求就響應客戶端,讀請求Master 獨立處理
  • 若是Master 崩潰了
    • 其餘服務器會在Master租期到期後,進入新一輪的選舉(選舉幾秒鐘結束)
  • 若是非Master 崩潰
    • 不影響,本身重啓便可
    • 長時間不能恢復,須要加入新的機器,配置DNS,Master是週期掃描DNS的,會很快感知到,其餘服務器複製Master方式很快知道

目錄與文件:數據結構

  • Chubby 的數據結構是目錄與文件組成的樹
  • ls是全部的前綴(根目錄 lock service)
  • foo 是Chubby 集羣的名字
  • 每一個節點分爲持久節點和臨時節點
    • 持久節點須要顯式的調用接口API進行刪除
    • 臨時節點和客戶鏈接session 綁定,會話失效後,自動刪除
      • 因此臨時節點能夠做爲客戶端有效性的判斷依據
  • 每一個節點都包含少許元數據信息
    • 包括權限控制的訪問控制列表(ACL)
    • 每一個元數據還包括4個單調遞增64位編號,分別是:
      • 實例編號:標示建立該實例節點的順序(即使名字相同,也能區別倆節點)
      • 文件內容編號(只針對文件):用於標示文件內容變化,文件內容被寫入時增長
      • 鎖編號:鎖狀態變動狀況,節點鎖在自由轉到被持有時增長
      • ACL編號:ACL被寫入時增長
      • 以外,還會提供64編號標識文件內容校驗

  • 鎖與鎖序列容器
    • 消息接受順序紊亂
      • 解決方案:虛擬時間、虛擬同步
  • Chubby 任意節點能夠充當讀寫鎖
    • 一種是排他模式持有鎖
    • 另外一種是共享鎖
  • Chubby 採用鎖延時、鎖序列器來解決消息延時和重排序引發的分佈式鎖問題
    • 正常釋放鎖,當即釋放
    • 異常釋放鎖,進行鎖延時
    • 鎖序列器:
      • 客戶端申請鎖序列器
      • 鎖名字、模式(排他、共享)、以及鎖序號
      • 使用時,客戶端將鎖序列器發給服務端
        • 服務端會檢查該鎖序列是否存在,客戶端是否處在合適的鎖模式

Chubby 中的事件通知機制架構

  • 客戶端能夠向服務端註冊事件通知,當這些事件發生時通知客戶端(消息異步發送)
  • 常見事件:
    • 文件內容變動
      • BigTable 集羣使用Chubby 肯定哪臺機器是Master
      • 得到鎖的BigTable Master 會將本身信息寫入Chubby對應文件中
      • BigTable 集羣中其餘機器經過關注Chubby 文件變化確認BigTable Master
    • 節點刪除
      • 節點刪除事件,一般臨時節點出現比較多,能夠此判斷客戶會話是否有效
    • 子節點新增刪除
    • Master 服務器轉移

Chubby 中的緩存併發

  • 在客戶端實現了緩存
  • 會在客戶端對文件內容和元數據進行緩存
    • 租期機制保證緩存的一致性
    • 緩存機制和Master的租期密切相關,Master維護客戶端緩存,
    • 向客戶端發送過時信息,保證客戶端要麼訪問一致性數據、要麼訪問不到數據
      • 若是數據修改,Master先阻塞該操做,先向全部可能緩存的客戶端發送過時信息,收到全部相關客戶端的應答,再修改

會話和會話激活(KeepAlive)異步

會話超時分佈式

Chubby Master 故障恢復

  • 客戶端會話到期,Master 的keepAlive 回覆未到,進入寬限期(默認45秒),客戶端先清空緩存
  • 新Master產生後,先肯定新的Master週期
    • 以後開始拒絕別的Master週期編號的請求(即使新的Master 和舊的是同一臺機器)
    • ,,,

Poxos 協議實現

  • 容錯日誌系統就是採用paxos算法實現的
  • 在此基礎上實現一致的狀態機副本,就是容錯數據庫
  • 一旦故障,恢復僅僅須要按照日誌再執行一遍
    • 根據本機日誌恢復,不行就從其餘節點獲取

Hypertable

  • Hypertable是C++開發的 開源、高性能、可伸縮數據庫
  • 目的是構建一個分佈式海量數據的高併發數據庫
  • 目前只支持增刪改查,不支持關聯查詢、事務處理等高級特性
  • 優點:

主要包括四個部分:

  • Hyperspace
    • 相似BigTable的Chubby
  • RangeServer
    • 對外提供服務的組件單元,負責數據的讀寫
  • Master 元數據管理中心
  • DFSBroker
    • 底層分佈式文件系統抽象層
相關文章
相關標籤/搜索