如何進行LogDevice與ApachePulsar之間的對比

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

成都創(chuàng)新互聯(lián)于2013年成立，先為鹽邊等服務建站，鹽邊等地企業(yè)，進行企業(yè)商務咨詢服務。為鹽邊企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。

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

架構(gòu)

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

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

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

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

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

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

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

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

一致性、多副本、Failover

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

LogDevice 和 Pulsar 都使用 ZooKeeper 決定 leader。

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

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

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

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

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

存儲

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

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

在有許多并發(fā)活躍日志時，LogDevice 和 Pulsar 存儲層都可以實現(xiàn)低延遲寫入。將多個日志的 entry 交叉放在幾個文件中，可以最小化隨機寫入。這樣對旋轉(zhuǎn)磁盤的影響較大，在旋轉(zhuǎn)磁盤上寫入多個文件意味著磁頭必須物理移動多次，但即使在固態(tài)磁盤上，優(yōu)先順序?qū)懭氡入S機寫入在性能上有更多優(yōu)勢。

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

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

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

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

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

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

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

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

看完上述內(nèi)容，你們掌握如何進行LogDevice與Apache Pulsar之間的對比的方法了嗎？如果還想學到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)站名稱：如何進行LogDevice與ApachePulsar之間的對比
標題網(wǎng)址：http://bm7419.com/article34/igeope.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、建站公司、面包屑導航、關(guān)鍵詞優(yōu)化、服務器托管、品牌網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)