共計 5108 個字符，預計需要花費 13 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關如何分析 Pulsar 的消息保留和過期策略，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
Apache Pulsar 是 Apache 軟件基金會頂級項目，是下一代云原生分布式消息流平臺，集消息、存儲、輕量化函數式計算為一體，采用計算與存儲分離架構設計，支持多租戶、持久化存儲、多機房跨區域數據復制，具有強一致性、高吞吐、低延時及高可擴展性等流數據存儲特性。
默認情況下，Pulsar Broker 會對消息做如下處理：
當消息被 Consumer 確認之后，會立即執行刪除操作。
對于未被確認的消息會存儲到 backlog 中。
但是，很多線上的生產環境下，這種默認行為并不能滿足我們的生產需求，所以，Pulsar 提供了如下配置策略來覆蓋這些行為：
Retention 策略：用戶可以將 Consumer 已經確認的消息保留下來。
TTL 策略：對于未確認的消息，用戶可以通過設置 TTL 來使未確認的消息到達已經確認的狀態。
上述兩種策略的設置都是在 NameSpace 的級別進行設置
Retention 策略
Retention 策略的設置提供了兩種方式：
消息的大小，默認值：defaultRetentionSizeInMB=0
消息被保存的時間，默認值：defaultRetentionTimeInMinutes=0
我們可以在 broker.conf 中對這兩項內容進行配置也可以通過命令行的形式。上文提到過，這兩種策略的設置，都是在 NameSpace 的級別進行設置，所以當我們使用命令行配置時，使用 NameSpaces 來進行配置，具體如下：
root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-retentionThe following options are required: --size, -s --time, -t
Set the retention policy for a namespaceUsage: set-retention [options] tenant/namespace Options: * --size, -s Retention size limit (eg: 10M, 16G, 3T). 0 or less than 1MB means no retention and -1 means infinite size retention * --time, -t Retention time in minutes (or minutes, hours, days, weeks eg: 100m, 3h, 2d, 5w). 0 means no retention and -1 means infinite time retention
如上所示：我們可以通過 -s 或者 -t 來指定我們需要配置的大小或者時間。
當你設置 Retention 策略之后，可以通過如下命令來查看具體的信息：
$ pulsar-admin namespaces get-retention [your tenant]/[your-namespace]{ retentionTimeInMinutes : 10, retentionSizeInMB : 0}Backlog
backlog 是未被確認消息的集合，它有一個大前提是，這些消息所在的 Topic 是被 Broker 所持久化的，在默認情況下，用戶創建的 Topic 都會被持久化。換句話說，Pulsar Broker 會將所有未確認或者未處理的消息都存放到 backlog 中。
同樣的，我們可以在 NameSpace 級別對 backlog 的大小進行配置。需要注意的是，對 backlog 進行配置時，我們需要明確以下兩點：
在當前的 NameSpace 下，每一個 Topic 允許的大小是多少
如果超過設定的 backlog 的閾值，將會執行哪些操作
當超過設定的 backlog 的閾值，Pulsar 提供了以下三種策略供用戶選擇：
你可以通過 set-backlog-quota 在 NameSpace 級別對 backlog 進行配置，具體如下：
root@e6df71e544ea:/pulsar# ./bin/pulsar-admin namespaces set-backlog-quotaThe following options are required: -l, --limit -p, --policy
Set a backlog quota policy for a namespaceUsage: set-backlog-quota [options] tenant/namespace Options: * -l, --limit Size limit (eg: 10M, 16G) * -p, --policy Retention policy to enforce when the limit is reached. Valid options are: [producer_request_hold, producer_exception, consumer_backlog_eviction]
如上所示，set-backlog-quota 提供了兩個參數，-l 用來指定你設置 backlog 的大小，-p 用來指定，當超過你設置的 backlog 的閾值之后，Broker 將會執行的策略。
當你設置 backlog 之后，可以通過如下命令，查看相應的信息：
$ pulsar-admin namespaces get-backlog-quotas [your tenant]/[your namespace]{ destination_storage : { limit : 2147483648, policy : producer_request_hold }}
如果你期望取消 backlog 的配置，可以使用如下命令：
$ pulsar-admin namespaces remove-backlog-quota [your tenant]/[your namespace]
當有消息積壓時，你可以通過 clear-backlog 來清除積壓的消息。清除 backlog 中積壓的消息是相對危險的操作，所以系統會提示你，是否確認要刪除 backlog 中的消息，clear-backlog 提供了 -f(–force) 的參數來屏蔽該提示。
$ pulsar-admin namespaces clear-backlog [your tenant]/[your namespace]
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 查看相應的配置信息，具體如下：
$ pulsar-admin namespaces get-message-ttl [your tenant]/[your namespace]60
TTL、Backlog 與 Retention 的區別和聯系
在上述的描述過程中，可以發現，TTL 只去處理一件事情，將未被確認的消息變為被確認的狀態，TTL 本身不會去涉及相應的刪除操作，具體如下圖所示：
在 T1 階段，m1-m5 這 5 條消息被確認，m6-m10 這 5 條消息未被確認在 T2 階段，對 m6、m7、m8 這三條消息設置 TTL 策略
在 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 的切換。
關于如何分析 Pulsar 的消息保留和過期策略就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
