默認情況下，Pulsar Broker 會對消息做如下處理：

• 當消息被 Consumer 確認之后，會立即執行刪除操作。

• 對于未被確認的消息會存儲到 backlog 中。

但是，很多線上的生產環境下，這種默認行為并不能滿足我們的生產需求，所以，Pulsar 提供了如下配置策略來覆蓋這些行為：

• Retention 策略：用戶可以將 Consumer 已經確認的消息保留下來。

• TTL 策略：對于未確認的消息，用戶可以通過設置 TTL 來使未確認的消息到達已經確認的狀態。

上述兩種策略的設置都是在 NameSpace 的級別進行設置

Retention 策略

Retention 策略的設置提供了兩種方式：

• 消息的大小，默認值：defaultRetentionSizeInMB=0

• 消息被保存的時間，默認值：defaultRetentionTimeInMinutes=0

我們可以在 broker.conf 中對這兩項內容進行配置也可以通過命令行的形式。上文提到過，這兩種策略的設置，都是在 NameSpace 的級別進行設置，所以當我們使用命令行配置時，使用 NameSpaces 來進行配置，具體如下：

如上所示：我們可以通過 -s 或者 -t 來指定我們需要配置的大小或者時間。

當你設置 Retention 策略之后，可以通過如下命令來查看具體的信息：

Backlog

backlog 是未被確認消息的集合，它有一個大前提是，這些消息所在的 Topic 是被 Broker 所持久化的，在默認情況下，用戶創建的 Topic 都會被持久化。換句話說，Pulsar Broker 會將所有未確認或者未處理的消息都存放到 backlog 中。

同樣的，我們可以在 NameSpace 級別對 backlog 的大小進行配置。需要注意的是，對 backlog 進行配置時，我們需要明確以下兩點：

• 在當前的 NameSpace 下，每一個 Topic 允許的大小是多少

• 如果超過設定的 backlog 的閾值，將會執行哪些操作

當超過設定的 backlog 的閾值，Pulsar 提供了以下三種策略供用戶選擇：

你可以通過 set-backlog-quota 在 NameSpace 級別對 backlog 進行配置，具體如下：

如上所示，set-backlog-quota 提供了兩個參數，-l 用來指定你設置 backlog 的大小，-p 用來指定，當超過你設置的 backlog 的閾值之后，Broker 將會執行的策略。

當你設置 backlog 之后，可以通過如下命令，查看相應的信息：

如果你期望取消 backlog 的配置，可以使用如下命令：

當有消息積壓時，你可以通過 clear-backlog 來清除積壓的消息。清除 backlog 中積壓的消息是相對危險的操作，所以系統會提示你，是否確認要刪除 backlog 中的消息， clear-backlog 提供了 -f(--force) 的參數來屏蔽該提示。

Time To Live （TTL）

默認情況下，Pulsar 會持久化所有未被確認的消息。如果未被確認的消息有很多，這種策略會造成大量的消息被積壓，導致磁盤空間增大。有些場景下，消息并不需要被持久化，用戶更期望的行為是，將這些未被確認的消息直接丟棄。這種情況下，你可以通過設置 TTL 使得未被確認的消息進入到被確認的狀態，當超過設定的 TTL 時間之后，配合相應的 Retention 策略將消息丟棄。

TTL 的一個典型使用場景是，當 Consumer 由于某些原因出現故障，不能正常消費消息，這時 Producer 還在不斷的往 Topic 中生產消息，會造成 Topic 中有大量的未確認的消息出現，這時你可以通過設置 TTL 將這些未確認的消息變為已確認的狀態。

同樣的，你可以在 Namesapce 級別下，通過指定 set-message-ttl 對 TTL 進行設置，具體命令如下：

root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-message-ttlThe following option is required: --messageTTL, -ttl
Set Message TTL for a namespaceUsage: set-message-ttl [options] tenant/namespace  Options:  * --messageTTL, -ttl       Message TTL in seconds       Default: 0

如上所示，set-message-ttl 只有一個參數 -ttl，單位為秒，默認值為 0。

當你設置 TTL 策略之后，可以通過 get-message-ttl 查看相應的配置信息，具體如下：

TTL、Backlog 與 Retention 的區別和聯系

在上述的描述過程中，可以發現，TTL 只去處理一件事情，將未被確認的消息變為被確認的狀態，TTL 本身不會去涉及相應的刪除操作，具體如下圖所示：

1. 在 T1 階段，m1-m5 這 5 條消息被確認，m6-m10 這 5 條消息未被確認
2. 在 T2 階段，對 m6、m7、m8 這三條消息設置 TTL 策略

3. 在 T3 階段，到達 TTL 設定的閾值，m6、m7、m8 這三條消息被確認

通過上圖可以看到，對于 backlog 中未被確認的消息，當你設置 TTL 之后，會將未確認消息的狀態變為確認的狀態。TTL 在這里所起到的作用就是將消息的 Cursor 從 m5 移動到 m8，m6、m7、m8 這三條消息變為已確認狀態。

Pulsar 是一個 multiple-subscription 的消息系統，對于 Topic 中的一條消息，只有當所有訂閱者都對這條消息 ack 或者消費了，它才能被刪除。

默認情況下，Pulsar Broker 會將所有未確認的消息持久化到 backlog 中。TTL 的功能是，你可以將這些未被確認的消息變為被確認的狀態，而 Retention 所關注的點是，當消息處于被確認的狀態時，你可以對已確認的消息進行的保留策略是什么。換句話說，backlog 是針對未確認的消息，Broker 所做的處理是什么。Retention 是針對已確認的消息，Broker 所做的保留策略是什么。

TTL 與死信隊列

死信隊列的相關介紹在此不做贅述。

在生產環境中，有時可能遇到質量差的數據是由于上游的原因導致的，必須由上游來解決，繼續嘗試處理其它的消息已經沒有意義，這時候用戶希望在發生錯誤時立即停止處理。Pulsar 中提供了一種特殊的 Topic——死信隊列。

死信隊列與 TTL 都可以將未確認的消息變為已確認的狀態。他們之間主要的不同在于，在上圖中的 T2 階段，TTL 只是將未確認的消息變為已確認的狀態，死信隊列的做法是將消息丟棄到死信隊列中，m6、m7、m8 這三條消息變為被確認的狀態。m9、m10 這兩條有效消息會正常處理，Broker 也會繼續運行。之后，你可以從死信隊列中檢查無效消息，并根據需要忽略或修復并重新處理。用戶可以根據自己的需求來確定未確認的消息是通過 TTL 的形式將其變為確認狀態還是通過死信隊列的方式來實現，依據的主要標準就是看你需不要處理消費不了的消息。

使用問題

• 場景一：

啟動 Producer 往 Broker 發送消息，設置了 TTL ，沒有啟動 Consumer，同時設置了 Retention 策略為半小時，到達 Retention 的閾值之后，發現設置 TTL 的消息并沒有被移除，這是為什么呢？

在上述場景中，有一個問題需要注意，沒有啟動 Consumer，在上面我們說到，TTL 是將消息設置的 Cousor 向前移動，如果沒有啟動 Consumer，相當于 Cousor 沒有被初始化，也就是如果沒有 Consumer，你就沒有必要去設置 TTL。

• 場景二：

我設置了Retention 策略，但是到達了 Retention 的閾值，Topic 中的數據并沒有被刪除掉，這是為什么呢？

這個是 Pulsar 內部的一個實現機制，在 Pulsar 中 Topic 是一個邏輯的概念，一個 Topic 對應一個 manage ledger，當你寫數據的時候，實際上是將數據寫到了 ledger 中，還記得在之前很多文章中提到的有關 Pulsar 設計的一個核心所在：在 Pulsar 中，所有的操作都是異步的，所以當 Retention 到達指定閾值之后，是否刪除對應 ledger 中的數據，這個操作也是異步的。delete 的操作是不會對當前 active 的 ledger 執行的。只有當數據寫滿了當前的 ledger ，ledger 發生切換時，才會去真正的執行 retention 策略。

如果想要強制執行，可以使用 pulsar-admin 將當前的 ledger 強制卸載，迫使其發生 ledger 的切換。