BookKeeper 設計介紹及應用
BookKeeper由yahoo於2009年建立,並在2011年開源。
BookKeeper是一個可靠的日誌流記錄系統,用於將系統產生的日誌(也可以是其他資料)記錄在BookKeeper叢集上,由BookKeeper這個第三方Storage保證資料儲存的可靠和一致性。典型場景是系統寫write-ahead log,即先把log寫到BookKeeper上,再對log做處理,比如將log寫到記憶體的資料結構中。BookKeeper同時適用於任何單點寫入並要求保證高效能和資料不丟失(Strong Durabilty Guarantees)的場景。
BookKeeper誕生於Hadoop2.0的namenode HA
BookKeeper介紹
BookKeeper帶有多個讀寫日誌的server,稱為 bookies。每一個bookie是一個BookKeeper的儲存服務,儲存了寫到BookKeeper上的write-ahead日誌,及其資料內容。寫入的log流(稱它為流是因為BookKeeper記錄的是byte[])稱為 ledgers,一個ledger是一個日誌檔案,每個日誌單元叫 ledger entry,也就是bookies是存ledgers的。ledger只支援append操作,而且同時只能有一個單執行緒來寫。ZK充當BookKeeper的元資料儲存服務,在
BookKeeper通過讀寫多個儲存節點達到高可用性,同時為了恢復由於異常造成的多節點資料不一致性,引入了資料一致性演算法。BookKeeper的可用性還體現在只要有足夠多的bookies可用,整個服務就可用。實際上,一份entry的寫入需要確保N份日誌冗餘在N個bookie上寫成功,而我們需要>N個bookie提供服務。在啟動BookKeeper的時候,需要指定一個ensemble值,即bookie可用的最小節點數量,還需要指定一個quorums值,即日誌寫入BookKeeper服務端的冗餘份數。BookKeeper的可擴充套件性體現在可以增加bookie數目,增加bookies可以提升讀寫吞吐量。
下面這張圖,展示了序列化日誌怎樣寫入到Bookie上。
Ledger記錄首先寫入到Journal,然後再寫入到Indexes和Entry Log。寫入到Journal是同步落盤持久化的。寫入到Entry Log的是先快取在Page Cache中,非同步刷盤。一般建議Journal與日誌實體(Entry Log/Ledger Indexes)分開儲存,避免寫入IO競爭。另外,為了寫入的高效能,Journal選擇SSD儲存;日誌實體可以儲存在通用的硬碟裝置上,比如JBOD。
由於不同Ledgers的記錄都是匯聚到一起寫入Entry Log的,即Bookies是順序寫,隨機讀的。為了提升讀取效能,Bookies給每個Ledger維護了一個Ledger Indexes。這個索引對映日誌實體(entries)位置與Ledger的關係(即entry log上哪個位置開始到哪個位置結束的資料屬於哪個Ledger)。
BookKeeper 在yahoo的訊息系統應用
雅虎多租戶分散式訊息系統,也叫雲訊息服務(CMS)。CMS在yahoo內部被60多個應用使用,包含移動訊息系統,天氣系統和廣告平臺、個性化平臺、主頁和儲存系統比如 Sherpa。
CMS提供盡力投遞(Best-Effort)和保證投遞(Guaranteed message delivery)。保證投遞需要適應網路,磁碟和伺服器故障。CMS使用BookKeeper作為儲存訊息,作為可靠訊息佇列。另外,在BookKeeper上維護每個訊息的消費位置,在至少一次(at-least-once)投遞場景下。
CMS使用BookKeeper的原因:
1、CMS已經部署在10+個數據中心,全網路備份。
2、大約100億訊息/天通過BookKeeper交換,預計到2015年底1000億訊息/天。
3、CMS已經部署了250+臺。到2015年底,期望部署1500+臺。
4、CMS目前有25000個佇列,將增長到百萬佇列。
5、CMS應用在雅虎的60多個伺服器應用中。
6、到目前為止,BookKeeper在CMS執行良好,使得有信心達到2015的目標。
未來的挑戰
BookKeeper在可擴充套件性和可靠性,有一些挑戰。下面是可以提升點:
1、優化Cache,提升每臺Bookie的吞吐量到10倍
2、每臺bookies上,增加5倍的ledgers。
3、提升租戶隔離效能,保證高讀負載
4、降低釋出時延到1ms以下。
參考: