升級(jí)后所遇到的問題

先來個(gè)欲揚(yáng)先抑，聊聊升級(jí)后所碰到的問題吧。

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

topic被刪除

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

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

圖片

最終定位是 topic 被刪除了。

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

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

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

監(jiān)控指標(biāo)丟失

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

圖片

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

最終丟失的指標(biāo)有這些：

• 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

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

新特性

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

支持低負(fù)載均衡

圖片

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

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

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

跳過空洞消息

圖片

Pulsar 可能會(huì)因?yàn)橄⑾M(fèi)異常導(dǎo)致游標(biāo)出現(xiàn)空洞，從而導(dǎo)致磁盤得不到釋放；

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

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

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

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

新的負(fù)載均衡器

同時(shí)也支持了一個(gè)新的負(fù)載均衡器，解決了以下問題：

• 以前的負(fù)載均衡大量依賴 zk，當(dāng) topic 數(shù)量增多時(shí)對(duì)擴(kuò)展性帶來問題。

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

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

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

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

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

第二個(gè)重大特性是支持大規(guī)模延遲消息，相信是有不少企業(yè)選擇 Pulsar 也是因?yàn)樗椭С盅舆t消息。

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

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

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

• 重啟 broker 時(shí)會(huì)消耗大量時(shí)候重建索引

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

待優(yōu)化功能

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

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

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

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

圖片

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

總結(jié)

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