升級后所遇到的問題

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

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

topic被刪除

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

結(jié)果哪知道第二天是被電話叫醒的，有部分業(yè)務(wù)反饋業(yè)務(wù)重啟之后就無法連接到 Pulsar 了。

圖片

最終定位是 topic 被刪除了。

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

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

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

監(jiān)控指標丟失

第二個問題不是那么嚴重，是升級后發(fā)現(xiàn)  bookkeeper 的一些監(jiān)控指標丟失了，比如這里的寫入延遲：

圖片

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

最終丟失的指標有這些：

• 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

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

新特性

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

支持低負載均衡

圖片

當我們升級或者是重啟 broker 的時候，全部重啟成功后其實會發(fā)現(xiàn)最后重啟的那個 broker 是沒有流量的。

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

本次 3.0 終于將那個優(yōu)化發(fā)版了，之后只要我們配置 lowerBoundarySheddingEnabled: true 就能開啟這個低負載均衡的一個特性，使得低負載的 broker 依然有流量進入。

跳過空洞消息

圖片

Pulsar 可能會因為消息消費異常導(dǎo)致游標出現(xiàn)空洞，從而導(dǎo)致磁盤得不到釋放；

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

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

具體 issue 和修復(fù)過程在這里：https://github.com/apache/pulsar/issues/20262 https://github.com/apache/pulsar/pull/20326

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

新的負載均衡器

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

• 以前的負載均衡大量依賴 zk，當 topic 數(shù)量增多時對擴展性帶來問題。

• 新的負載均衡器使用 non-persistent 來存儲負載信息，就不再依賴 zk 。

• 以前的負載均衡器需要依賴 leader broker 進行重定向到具體的 broker，其實這些重定向并無意義，徒增了系統(tǒng)開銷。

• 新的負載均衡器使用了 SystemTopic 來存放 topic 的所有權(quán)信息，這樣每個 broker 都可以拿到數(shù)據(jù)，從而不再需要從 leader broker 重定向了。

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

支持大規(guī)模延遲消息

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

我們也是大量在業(yè)務(wù)中使用延遲消息，以往的延遲消息有著以下一些問題：

• 內(nèi)存開銷過大，延遲消息的索引都是保存在內(nèi)存中，即便是可以分布在多個 broker 中分散存儲，但消耗依然較大

• 重點優(yōu)化了索引的內(nèi)存占有量。

• 重啟 broker 時會消耗大量時候重建索引

• 支持了索引快照，最大限度的降低了構(gòu)建索引的資源消耗。

待優(yōu)化功能

監(jiān)控面板優(yōu)化

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

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

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

圖片

目前還在開發(fā)中，大概類似于這樣的數(shù)據(jù)。

總結(jié)

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