如何進行LogDevice與Apache Pulsar之間的對比

如何進行LogDevice與Apache Pulsar之間的對比，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

Facebook 已經發布開源 LogDevice。考慮到 LogDevice 目標用例之間的相似性，自然會有人問到 LogDevice 與 Apache Pulsar 之間是否也有相似之處。本文將對這一問題進行解答。對比 LogDevice 和 Pulsar 并不簡單，LogDevice 的操作級別要比 Pulsar 低。LogDevice 與 Twitter 的 DistributedLog 更相似。二者都只關注日志原語，而不關注 schema 管理、多租戶、光標管理等高級功能。這些高級功能將留給用戶基于 LogDevice 去實現。下面將討論 LogDevice 和 Pulsar 中都有的基本元素：分布式日志。

架構

LogDevice 向用戶顯示一個日志原語。寫入客戶端將 entry 寫入 sequencer 節點。該節點將日志序列號（LSN）分配給所有 entry，然后將 entry 寫入已經分配給日志的較大節點集的一個子集（副本集）。LogDevice 的 sequencer 類似于 Pulsar 中的 broker，在 Pulsar 中，由 broker 分配消息 ID 并發送消息到 Apache BookKeeper 進行存儲。

LogDevice 和 Pulsar 在架構方面有許多相同之處，比如它們都將計算與存儲分離。與單片架構相比，這種架構具有以下優勢：

?單個日志可以無限增長?出現節點故障時，可以進行無縫恢復?集群擴展簡單?讀寫具有獨立可擴展性

比較 Pulsar 和 Kafka：基于分片的架構如何提升整體性能、延展性與彈性^[2]一文中詳細說明了這種架構的優勢。Pulsar 和 LogDevice 都具備這些優勢。

LogDevice 和 Pulsar 讀取數據的方式有所不同。在 Pulsar 中，讀客戶端在 broker 上訂閱 topic，并從 broker 上接收消息；而在 LogDevice 中，讀客戶端直接與存儲節點相連。

像 LogDevice 這樣直接從存儲節點讀取數據，允許讀操作有更大程度的扇出。也就是說，由于讀取器不需要訪問同一節點，系統可以在單個 topic 上支持更多讀取器。

但是，在需要保證日志的一致性時，直接從存儲節點讀取數據會加長延遲。如果寫入器沒有確認寫入的 entry，讀取器無法讀取該 entry。從存儲節點讀取數據時，需要以某種方式通知存儲節點 entry 已經被復制到足夠多的節點上，并將 ack 發送到寫入器，在此之前 entry 不可讀。

在 Pulsar 中，客戶端通過 broker 進行讀寫。這種讀寫方式在延遲和性能上都有優勢。由于在同一個節點上進行讀寫，所以在將 entry ack 發送到寫入器時，該 entry 立即可讀。Pulsar 通過在 broker 上控制讀寫，得以支持更復雜的訂閱模型，如共享訂閱、Failover 訂閱^[3]等。

一致性、多副本、Failover

LogDevice 和 Pulsar 采用相似的技術實現全局順序廣播協議（TOAB）^[4]。將日志分為不同 epoch，每個節點（leader）可以決定該 epoch 中 entry 的序列號，并且相應機制保證不會寫入以前的 epoch。

LogDevice 和 Pulsar 都使用 ZooKeeper 決定 leader。

在 LogDevice 中，leader 也稱作 sequencer。每個日志都有一個 sequencer，每個 sequencer 都被（從 ZookKeeper）分配了一個“epoch”號。LSN 由 epoch 和一個局部單調遞增組件組成，sequencer 決定每個 entry 的 LSN，并將 epoch 中的 entry 轉發到一組存儲節點上。當足夠多的存儲節點 ack entry 時，sequencer 將 ack 發送到發起寫請求的客戶端。在 sequencer 出現故障時，就會有新的 sequencer 獲取新的 epoch，并可以立即服務于寫入操作。在后臺啟動一個“封閉”前一個 epoch 的操作，則會禁止從新 epoch 進行讀取的操作，直到前一個 epoch 被封。“封閉”操作涉及從節點集向足夠多的存儲節點通知新 epoch 的存在，因此寫入操作就不會有足夠多的 ack 來向客戶端 ack 寫入操作。

對于 Pulsar 來說，epoch 就是 BookKeeper ledger。每個 topic 都有 BookKeeper ledger 列表，這些列表組成了 topic 的全部日志。當一個 Pulsar broker 崩潰時，另一個 broker 會接管這一 topic，由此保證封閉前一個 broker 中的 ledger，創建自己的 ledger，并將其添加至 topic 的 ledger 列表中。最后三個操作涉及到了 ZooKeeper。一旦更新了 topic 的 ledger 列表，broker 就可以開始為 topic 上的讀寫提供支持。所有向 topic 寫入的數據在被 ack 并且對讀取器可見之前都會持久化到 BookKeeper ledger 上，存儲在一組存儲節點中。

對于 LogDevice 和 Pulsar（采用 BookKeeper）來說，entry 持久化只需要一個 entry 命中一個節點子集，因此在有緩慢的或故障的存儲節點時，可以保持低延遲的寫入。

在檢測到 leader 出現故障時，LogDevice 可以在發現故障后很快地提供寫服務，只需要兩次往返 ZooKeeper 來選擇一個 sequencer。在 Pulsar 中，再次寫入前，需要先恢復之前的 ledger，恢復操作包括與一些存儲節點對話、向 ZooKeeper 進行新的寫入等。另外，在 Pulsar 中，可以同時恢復讀寫，而在 LogDevice 中，讀取之前，必須進行“封閉”操作，類似于 ledger 的恢復操作。

我們猜測 LogDevice 不允許在上一個 epoch “封閉”之前寫入，因其讀操作不協調，與性能無關。不管是否封閉前一個 epoch，檢測到 sequencer 發生故障會占用恢復時間。允許寫入前的封閉操作需要 sequencer 與讀取器進行協調，這樣收效甚微，但卻會增加復雜性。在 Pulsar 中，由于是在 broker 上進行讀取，在寫入前恢復之前的 ledger 就很容易。

存儲

LogDevice 存儲節點將 entry 存儲在 RocksDB 中。Entry 存儲在按時間順序排列的列族集合中，entry 由日志 ID 和 entry 的 LSN 組合進行鍵控。簡單來說，每個存儲節點都有許多按時間順序排列的 RocksDB 實例，只向最新的 RocksDB 實例寫入。這些 RocksDB 實例盡量確保只進行少量壓縮，以避免寫入放大。

Pulsar 存儲節點（BookKeeper）上有一個日志、一個 entry 日志和一個索引。日志有專用磁盤。當向 bookie 寫入 entry 時，其實是在向日志磁盤寫入，并向寫入器 ack。然后，將 entry 放入一個暫存區域，當此區域內有足夠多的 entry 時，就通過 ledger ID 和 entry ID 進行存儲，flush 到 entry 日志。此時，entry 日志中的每條 entry 都已寫入索引，索引正是一個 RocksDB 實例。

在有許多并發活躍日志時，LogDevice 和 Pulsar 存儲層都可以實現低延遲寫入。將多個日志的 entry 交叉放在幾個文件中，可以最小化隨機寫入。這樣對旋轉磁盤的影響較大，在旋轉磁盤上寫入多個文件意味著磁頭必須物理移動多次，但即使在固態磁盤上，優先順序寫入比隨機寫入在性能上有更多優勢。

但是，交錯寫入也意味著要進行更多讀取。

日志系統中的讀取通常分為兩類，追尾讀和追趕讀。對于追尾讀，LogDevice 和 Pulsar 都不太可能命中磁盤，因為所需數據在某種程度上仍然應該存儲在內存緩存中；而追趕讀最終都會命中磁盤。吞吐量通常比追趕讀延遲更重要，LogDevice 和 Pulsar 的設計都與此相符。

雖然大多數讀取應該是連續的，但是 LogDevice 需要讀取許多 SST 文件來進行追趕讀。因為 RocksDB 在將 entry flush 到磁盤前會按鍵排序。這樣就會分不清楚是否在同一磁盤讀寫。如果是，追趕讀可能會影響系統的寫入性能。

RocksDB 允許配置多個路徑，將舊 SST 文件與新 SST 文件分開存儲。

由于 Pulsar 將寫入的關鍵路徑保存在單獨的磁盤上，讀取操作完全獨立。讀取通常也是有序的，因為 entry 日志中的數據在 flush 到磁盤前按照 ledger 和 entry ID 排序。

LogDevice 盡量避免壓縮，因此會放大寫入。這對于日志系統說得通，因為不需要讀取寫入的大部分數據，但會影響數據保留。不能刪除單個日志，因此系統中所有日志的保存時間都必須由保留時間決定。集群內的所有日志都不能永久保存，有些甚至只能保存幾個小時。

在 Pulsar 中，要從存儲節點刪除日志，就需要先從索引中刪除。因此，索引會經常壓縮，但是由于 entry 數據本身不在索引中，這也影響不大。存儲節點監聽索引引用每個 entry 日志的百分比。一旦一個 entry 日志低于某個閾值，則復制活躍數據到新的“壓縮” entry 日志中，更新索引，并刪除原 entry 日志。

LogDevice 是對分布式日志空間的有趣補充。Pulsar 不僅是分布式日志系統，更是一個完整的消息平臺，因此不能將 LogDevice 直接與 Pulsar 進行比較，但很高興看到 LogDevice 團隊決定采用與 Pulsar 類似的架構。現在 LogDevice 已經開源，十分期待它的使用。

看完上述內容，你們掌握如何進行LogDevice與Apache Pulsar之間的對比的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！