為什么要選擇Apache BookKeeper

本篇文章為大家展示了為什么要選擇Apache BookKeeper，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

我將會介紹 Apache BookKeeper 一系列具有競爭力的功能，主要包括 I/O 隔離、數據分布、可擴展性與可操作性。

 I/O 隔離

可預測的低延遲對實時應用程序而言十分重要，特別是關鍵在線服務（例如：核心業務服務、數據庫等）。以消息系統為例，在大多數消息系統中，速度較慢的 consumer 可能會導致消息積壓，這有可能會進一步導致總體性能下降。

問題在于，較慢的 consumer 迫使存儲系統從持久存儲介質中讀取數據，這會導致 I/O 抖動及頁面緩存的換入換出。當存儲 I/O 組件共享用于寫入、追尾讀、追趕讀的單一路徑時，就會發生這種情況。

在 BookKeeper 中，bookie（單個 BookKeeper 存儲節點）旨在使用三條獨立的 I/O 路徑，分別用于寫入、追尾讀、追趕讀。分離這三個路徑很重要，因為寫入和追尾讀對可預測的低延遲有較高要求，而追趕讀則對吞吐量的要求比較高。在這些工作負載之間提供物理隔離意味著 BookKeeper 能夠充分利用以下幾點：

• 寫入時，網絡入口帶寬和順序寫入帶寬

• 讀取時，多個 ledger 磁盤上網絡出口帶寬和 IPOS（每秒輸入/輸出操作數）
  

I/O 隔離意味著 BookKeeper 能夠在不妨礙其他優勢的條件下，同時提供上述優勢。

數據分布

建立在 BookKeeper 上的服務（比如：Apache Pulsar）將日志流作為分片 ledgers 存儲在 BookKeeper 上。這些分片（ledgers）會被復制到多個 bookie。這樣可以使數據存放有盡可能多的選擇，從而實現高可用、流量負載均衡、運維簡單等。我將從部署和運維的角度介紹一些優勢。

首先，單個日志流的存儲容量永遠不會受到單個主機存儲容量的限制。只要整個集群有足夠的容量，就可以存儲數據。

其次，在擴展 BookKeeper 集群時，不涉及日志流再平衡。管理員可以通過增加新設備來擴展 BookKeeper 集群。集群可以發現新的 bookie，并向其寫入分片。BookKeeper 還提供了多種分布策略，包括機架感知、區域感知、基于重量的布局策略等，以實現盡可能多的布局方式。

再次，BookKeeper 能夠在發生機器故障時更快、更高效地進行副本修復。當一個分片由于機器故障丟失或由于磁盤故障損壞時，BookKeeper 可以確定哪些分片需要修復（重新復制 entry 以滿足副本要求），并從多個主機同時進行修復。

相比于 Apache Kafka 這樣以分區為中心的系統，BookKeeper 可水平擴展的性能更具優勢。在 Apache Kafka 中，日志流（又稱 Kafka 分區）僅順序存儲在一部分機器上，并且擴展 Kafka 集群需要大量數據進行再平衡，而再平衡操作本身就很消耗資源、易出錯，且運維復雜。

另外，在以分區為中心的系統上，損壞的單個磁盤要求系統復制整個日志流到新磁盤，以滿足多副本要求。

所有的日志分片跨 N 個可能的 bookie 復制到可配置數量的 bookie 上（圖示中副本數為 3）。日志分片均勻分布，以在不重新平衡的條件下實現水平擴展。

可擴展

作為一個實時日志流存儲平臺，能夠隨著流量的增加或寫入系統的數據增多而進行擴展是十分重要的。Apache BookKeeper 基于以下幾點實現其可擴展性：

流可擴展性能夠支持大量日志流的存儲，在 ledger 或流的數量從數百增為數百萬時，其他性能不受影響。實現流可伸縮性的關鍵在于存儲格式。

如果 ledger 和流都存儲在專用文件中，流伸縮性的實現就會出現問題，因為當這些文件定期從頁面緩存刷新到磁盤時，I/O 會分散在磁盤上。

BookKeeper 以交錯存儲格式存儲 ledger 和流的數據，整合來自不同 ledger 和流的 entry，并存儲在大文件中，然后進行索引。這既減少了文件數量，也減少了 I/O 爭用，允許 BookKeeper 為大量 ledger 和流進行擴展。

Bookie 可伸縮性，即日志流存儲通過添加 bookie（BookKeeper 中的存儲節點）來支持迅速增加的流量。在 BookKeeper 中，bookie 之間不直接交互。這使得 BookKeeper 只需添加新機器即可擴展集群。

同樣，由于 BookKeeper 在 bookie 上分發數據的方式，在擴展 BookKeeper 集群時，分區數據并不昂貴，也不會耗盡系統網絡和 I/O 帶寬。不管數據如何分配，這都可以增加集群的大小。

雅虎（Yahoo!）和推特（Twitter）都在使用 BookKeeper，在單個集群上有成百上千個 bookie。

客戶端可伸展性，即日志流存儲支持大量并發客戶端并支持大量扇出的能力。BookKeeper 可在多處實現此功能：

• 客戶端和服務器都完全使用 Netty 來實現異步網絡 I/O。所有網絡 I/O 使用單個 TCP 連接進行多路復用，并且都是異步的。以很少的資源消耗實現了非常高效的管道和極高的吞吐量。

  
  

• 復制數據到多個 bookie。在 bookie 副本間，數據是完全相同的。在 Apache Kafka 這樣的系統中，客戶端只能從 leader 節點讀取數據。而 BookKeeper 的客戶端可以從任一 bookie 副本中讀取數據（這種讀取可重復）。這不僅實現了較高的讀可用性，還能平均分配讀取流量。

  
  

• 由于客戶端能夠重復地從任一 bookie 副本讀取數據，應用程序可以配置更多的副本來實現更高的讀取扇出。
  

應用程序可以通過使用更多的流或增加 bookie 來提高吞吐量。另外，BookKeeper 還可以通過增加 ensemble 大小（ensemble 是用于存儲給定 ledger 或流的 bookie 子集），并在 bookie 之間分段數據來調節單流吞吐量。

對于那些需要對單個流進行數據排序的有狀態應用程序而言，這是至關重要的。

運維簡單

Apache BookKeeper 旨在運維簡單。在系統運行時，可以通過添加 bookie 節點輕易擴展容量。如果一個 bookie 節點不再自動可用，此 bookie 中包含的所有 entry 將被標記為"已復制"，BookKeeper 自動恢復守護進程自動將其他可用副本中的數據再復制到新的 bookie 節點。

在運行 bookie 節點時，BookKeeper 提供只讀模式。在某些情況下，例如：磁盤已滿、磁盤損壞，bookie 自動變為只讀模式。只讀模式下，bookie 不允許寫入數據，但仍可以讀取流量。這種自愈性減少了許多運維上的痛點問題。

另外，BookKeeper 提供了多種管理集群的方法，包括使用管理 CLI 工具、Java 管理庫、HTTP REST API 等。REST API 具有編寫外掛工具或在現有工具中使用某些操作的靈活性。

安全性

Apache BookKeeper 支持可插拔的身份驗證機制(http://bookkeeper.apache.org/docs/latest/security/overview/)，應用程序可以使用該機制進行自身身份驗證。BookKeeper 也可以配置為支持多種身份驗證機制。身份驗證程序的目的在于建立客戶端的身份，并為客戶端分配一個標識符。

該標識符可用來確定客戶端被授權執行的操作。默認情況下，BookKeeper 支持兩種身份驗證程序：TLS、SASL。

上述內容就是為什么要選擇Apache BookKeeper，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。