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以下。

參考：