Pulsar3.0新功能介紹

在上一篇文章 Pulsar3.0 升級指北講了關於升級 Pulsar 集羣的關鍵步驟與災難恢復，本次主要分享一些 Pulsar3.0 的新功能與可能帶來的一些問題。

升級後所遇到的問題

先來個欲揚先抑，聊聊升級後所碰到的問題吧。

其中有兩個問題我們感知比較明顯，特別是第一個。

topic被刪除

我們在上個月某天凌晨從 2.11.2 升級到 3.0.1 之後，進行了上一篇文章中所提到的功能性測試，發現沒什麼問題，覺得一切都還挺順利的，半個小時搞定後就下班了。

結果哪知道第二天是被電話叫醒的，有部分業務反饋業務重啓之後就無法連接到 Pulsar 了。

最終定位是 topic 被刪除了。

其中的細節還蠻多的，修復過程也是一波三折，後面我會單獨寫一篇文章來詳細梳理這個過程。

在這個 issue 和 PR 中有詳細的描述：
https://github.com/apache/pulsar/issues/21653
https://github.com/apache/pulsar/pull/21704

感興趣的朋友也可以先看看。

監控指標丟失

第二個問題不是那麼嚴重，是升級後發現 bookkeeper 的一些監控指標丟失了，比如這裏的寫入延遲：

我也定位了蠻久，但不管是官方的 docker 鏡像還是源碼編譯都無法復現這個問題。

最終丟失的指標有這些：

• bookkeeper_server_ADD_ENTRY_REQUEST
• bookkeeper_server_ADD_ENTRY_BLOCKED
• bookkeeper_server_READ_ENTRY_BLOCKED
• bookie_journal_JOURNAL_CB_QUEUE_SIZE
• bookie_read_cache_hits_count
• bookie_read_cache_misses_count
• bookie_DELETED_LEDGER_COUNT
• bookie_MAJOR_COMPACTION_COUNT

詳細內容可以參考這個 issue：
https://github.com/apache/pulsar/issues/21766

新特性

講完了遇到的 bug，再來看看帶來的新特性，重點介紹我們用得上的特性。

支持低負載均衡

當我們升級或者是重啓 broker 的時候，全部重啓成功後其實會發現最後重啓的那個 broker 是沒有流量的。

這個原理和優化在之前寫過的 Pulsar負載均衡原理及優化 其實有詳細介紹。

本次 3.0 終於將那個優化發版了，之後只要我們配置 lowerBoundarySheddingEnabled: true 就能開啓這個低負載均衡的一個特性，使得低負載的 broker 依然有流量進入。

跳過空洞消息

Pulsar 可能會因爲消息消費異常導致遊標出現空洞，從而導致磁盤得不到釋放；

所以我們有一個定時任務，會定期掃描積壓消息的 topic 判斷是否存在空洞消息，如果存在便可以在管理臺使用 skipMessage API 跳過空洞消息，從而釋放磁盤。

但在 3.0 之前這個跳過 API 存在 bug，只要跳過的數量超過 8 時，實際跳過的數量就會小於 8.

具體 issue 和修復過程在這裏：
https://github.com/apache/pulsar/issues/20262
https://github.com/apache/pulsar/pull/20326

總之這個問題在 3.0 之後也是修復了，有類似需求的朋友也可以使用。

新的負載均衡器

同時也支持了一個新的負載均衡器，解決了以下問題：

• 以前的負載均衡大量依賴 zk，當 topic 數量增多時對擴展性帶來問題。
  • 新的負載均衡器使用 non-persistent 來存儲負載信息，就不再依賴 zk 。
• 以前的負載均衡器需要依賴 leader broker 進行重定向到具體的 broker，其實這些重定向並無意義，徒增了系統開銷。
  • 新的負載均衡器使用了 SystemTopic 來存放 topic 的所有權信息，這樣每個 broker 都可以拿到數據，從而不再需要從 leader broker 重定向了。

更多完整信息可以參考這個 PIP: PIP-192: New Pulsar Broker Load Balancer

支持大規模延遲消息

第二個重大特性是支持大規模延遲消息，相信是有不少企業選擇 Pulsar 也是因爲他原生就支持延遲消息。

我們也是大量在業務中使用延遲消息，以往的延遲消息有着以下一些問題：

• 內存開銷過大，延遲消息的索引都是保存在內存中，即便是可以分佈在多個 broker 中分散存儲，但消耗依然較大
  • 重點優化了索引的內存佔有量。
• 重啓 broker 時會消耗大量時候重建索引
  • 支持了索引快照，最大限度的降低了構建索引的資源消耗。

待優化功能

監控面板優化

最後即便是升級到了 3.0 依然還有一些待優化的功能，在之前的 從 Pulsar Client 的原理到它的監控面板中有提到給客戶端加了一些監控埋點信息。

最終使用下來發現還缺一個 ack 耗時的一個面板，其實日常碰到最多的問題就是突然不能消費了（或者消費過慢）。

這時如果有這樣的耗時面板，首先就可以定位出是否是消費者本身的問題。

目前還在開發中，大概類似於這樣的數據。

總結

Pulsar3.0 是 Pulsar 的第一個 LTS 版本，推薦儘快升級可以獲得長期支持。
但只要是軟件就會有 bug，即便是 LTS 版本，所以大家日常使用碰到 Bug 建議多向社區反饋，一起推動 Pulsar 的進步。