如何分析Pulsar的消息保留和過期策略

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

• 當(dāng)消息被 Consumer 確認之后，會立即執(zhí)行刪除操作。

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

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

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

• TTL 策略：對于未確認的消息，用戶可以通過設(shè)置 TTL 來使未確認的消息到達已經(jīng)確認的狀態(tài)。

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

Retention 策略

Retention 策略的設(shè)置提供了兩種方式：

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

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

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

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

當(dāng)你設(shè)置 Retention 策略之后，可以通過如下命令來查看具體的信息：

Backlog

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

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

• 在當(dāng)前的 NameSpace 下，每一個 Topic 允許的大小是多少

• 如果超過設(shè)定的 backlog 的閾值，將會執(zhí)行哪些操作

當(dāng)超過設(shè)定的 backlog 的閾值，Pulsar 提供了以下三種策略供用戶選擇：

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

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

當(dāng)你設(shè)置 backlog 之后，可以通過如下命令，查看相應(yīng)的信息：

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

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

Time To Live （TTL）

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

TTL 的一個典型使用場景是，當(dāng) Consumer 由于某些原因出現(xiàn)故障，不能正常消費消息，這時 Producer 還在不斷的往 Topic 中生產(chǎn)消息，會造成 Topic 中有大量的未確認的消息出現(xiàn)，這時你可以通過設(shè)置 TTL 將這些未確認的消息變?yōu)橐汛_認的狀態(tài)。

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

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 只有一個參數(shù) -ttl，單位為秒，默認值為 0。

當(dāng)你設(shè)置 TTL 策略之后，可以通過 get-message-ttl 查看相應(yīng)的配置信息，具體如下：

TTL、Backlog 與 Retention 的區(qū)別和聯(lián)系

在上述的描述過程中，可以發(fā)現(xiàn)，TTL 只去處理一件事情，將未被確認的消息變?yōu)楸淮_認的狀態(tài)，TTL 本身不會去涉及相應(yīng)的刪除操作，具體如下圖所示：

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

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

通過上圖可以看到，對于 backlog 中未被確認的消息，當(dāng)你設(shè)置 TTL 之后，會將未確認消息的狀態(tài)變?yōu)榇_認的狀態(tài)。TTL 在這里所起到的作用就是將消息的 Cursor 從 m5 移動到 m8，m6、m7、m8 這三條消息變?yōu)橐汛_認狀態(tài)。

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

默認情況下，Pulsar Broker 會將所有未確認的消息持久化到 backlog 中。TTL 的功能是，你可以將這些未被確認的消息變?yōu)楸淮_認的狀態(tài)，而 Retention 所關(guān)注的點是，當(dāng)消息處于被確認的狀態(tài)時，你可以對已確認的消息進行的保留策略是什么。換句話說，backlog 是針對未確認的消息，Broker 所做的處理是什么。Retention 是針對已確認的消息，Broker 所做的保留策略是什么。

TTL 與死信隊列

死信隊列的相關(guān)介紹在此不做贅述。

在生產(chǎn)環(huán)境中，有時可能遇到質(zhì)量差的數(shù)據(jù)是由于上游的原因?qū)е碌?，必須由上游來解決，繼續(xù)嘗試處理其它的消息已經(jīng)沒有意義，這時候用戶希望在發(fā)生錯誤時立即停止處理。Pulsar 中提供了一種特殊的 Topic——死信隊列。

死信隊列與 TTL 都可以將未確認的消息變?yōu)橐汛_認的狀態(tài)。他們之間主要的不同在于，在上圖中的 T2 階段，TTL 只是將未確認的消息變?yōu)橐汛_認的狀態(tài)，死信隊列的做法是將消息丟棄到死信隊列中，m6、m7、m8 這三條消息變?yōu)楸淮_認的狀態(tài)。m9、m10 這兩條有效消息會正常處理，Broker 也會繼續(xù)運行。之后，你可以從死信隊列中檢查無效消息，并根據(jù)需要忽略或修復(fù)并重新處理。用戶可以根據(jù)自己的需求來確定未確認的消息是通過 TTL 的形式將其變?yōu)榇_認狀態(tài)還是通過死信隊列的方式來實現(xiàn)，依據(jù)的主要標(biāo)準(zhǔn)就是看你需不要處理消費不了的消息。

使用問題

• 場景一：

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

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

• 場景二：

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

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

如果想要強制執(zhí)行，可以使用 pulsar-admin 將當(dāng)前的 ledger 強制卸載，迫使其發(fā)生 ledger 的切換。