官網原文標題《Concepts and Architecture--Topic Compaction》

翻譯時間：2018-11-01

譯者：本文介紹了Pulsar中主題壓縮的概念。

------------------------------------------------------------------

Topic壓縮

訊息資料高度可擴充套件的持久儲存是Pulsar構建的主要目標。 Pulsar的topic讓你可以持久儲存你所需要的這麼多未被確認的訊息，同時保留了訊息的順序。 預設的，Pulsar儲存生產到主題上所有未被確認/未被處理的訊息。 在很多Pulsar的使用案例中，在topic累計大量的未被確認的訊息是有必要的。但對於Pulser的consumer來說，在完整的訊息log中進行回退，將變得非常耗時。

某些情況下，consumer並不需要完整的topic日誌。 他們可能只需要幾個值來構造一個更 "淺" 的日誌影象, 也許僅僅只是最近的值。 對於這種應用場景，Pulsar提供了 topic壓縮. 當你在topic上執行壓縮，Pulsar會遍歷topic的backlog然後把遙遠模糊已經有了更新的訊息移除。例如，它遍歷一個以key為基礎的topic，只留下關聯到key上最新的訊息。

Pulsar的topic壓縮特性：

• 允許通過主題日誌更快地 "後退"
• 僅適用於 永續性topic
• 當backlog達到一定大小時，可以被自動出發，或者通過命令列手動出發。請參見Topic compaction cookbook
• 在概念上和操作上與 retention和expiry 是不同的。 但是，在topic壓縮中，還是會尊重retention。 如果retention已經從topic的backlog中移除了訊息，那麼此條訊息在壓縮的topic賬簿上也是無法被讀取的。

Topic壓縮示例：股票報價機

Pulsar topic壓縮的一個使用例子，可以看一下股票報價機topic。 在股票報價機topic中，每條訊息都有帶有時間戳的股票買入價格（包含代表股票符號的訊息key，例如AAPL或者GOOG）。 可能你感興趣的只是股票報價機中最新的股票價格，而對歷史資料並不感興趣（即你不需要構建topic每個key下訊息序列的完整影象）。 壓縮在這種場景下非常的方便，因為它使得使用者不需回退到模糊的訊息上。

Topic壓縮的工作原理

當通過命令列觸發topic壓縮，Pulsar將會從頭到尾迭代整個topic。 對於它碰到的每個key，壓縮程式將會只保留這個key最近的事件。

之後，broker將會建立一個新的BookKeeper ledger 然後開始對topic的每條訊息進行第二次迭代。 對於每條訊息，如果key匹配到它的最新事件，key的資料內容，訊息ID，元資料將會被寫入最新建立的ledger。 如果key並沒有匹配到最新的訊息，訊息將被跳過。 如果給定的訊息，負載是空的，它將被跳過並且視為刪除（類似key-value資料庫中的 tombstones概念）； 在本topic第二次迭代結束時，新建立的BookKeeper ledger將被關閉，並將兩個內容寫入元資料 ：BookKeeper ledger的ID及最新被壓縮的訊息的ID（這被稱為topic的壓縮層位）。 寫入元資料後，壓縮就完成了。

初始化壓縮操作完成後，將來任何對壓縮層位及壓縮backlog的修改，都會通知給擁有該topic的Pulsar broker。

當下列更改發生時：

• 啟用讀取壓縮功能的客戶端（consumer和reader），將會嘗試從topic中讀取訊息，或者：
  • 像從正常的主題那樣讀取（如果訊息的ID大於等於壓縮層位），或
  • 從壓縮層位的開始讀取（如果訊息ID小於壓縮層位）