業(yè)務(wù)消息量大，對(duì)生產(chǎn)與消費(fèi)耗時(shí)指標(biāo)敏感

Data 項(xiàng)目的業(yè)務(wù)場(chǎng)景，具有非常明顯的特點(diǎn)。首先，業(yè)務(wù)系統(tǒng)運(yùn)行過(guò)程中，消息的生產(chǎn)、消費(fèi)量都非常大，而且生產(chǎn)消息的 QPS（每秒查詢率）波動(dòng)性不明顯，即業(yè)務(wù)會(huì)在近乎固定的 QPS 生產(chǎn)和消費(fèi)數(shù)據(jù)。

其次，業(yè)務(wù)方對(duì)系統(tǒng)的可靠性、生產(chǎn)耗時(shí)、消費(fèi)耗時(shí)這幾個(gè)指標(biāo)項(xiàng)比較敏感，需要在比較低的延遲基礎(chǔ)上完成業(yè)務(wù)處理流程。像 Data 項(xiàng)目這樣的業(yè)務(wù)場(chǎng)景和需求，對(duì)集群的部署、運(yùn)營(yíng)和系統(tǒng)穩(wěn)定性都提出了非常高的要求。

Data 項(xiàng)目集群最大的特點(diǎn)是消息量大、節(jié)點(diǎn)多，一個(gè)訂閱里可高達(dá)數(shù)千消費(fèi)者。雖然 Data 項(xiàng)目當(dāng)前 Topic 總量并不多，但單個(gè) Topic 對(duì)應(yīng)的客戶端比較多，每個(gè)分區(qū)要對(duì)應(yīng) 100+ 個(gè)生產(chǎn)者和 10000+個(gè)消費(fèi)者。在對(duì)消息系統(tǒng)選型時(shí)，團(tuán)隊(duì)將消息系統(tǒng)的低延遲、高吞吐設(shè)為關(guān)鍵指標(biāo)。經(jīng)過(guò)綜合對(duì)比市面上常見(jiàn)的消息系統(tǒng)，Apache Pulsar 憑借其功能和性能勝出。

Apache Pulsar 提供了諸多消費(fèi)模型如獨(dú)占、故障轉(zhuǎn)移、共享（Shared）和鍵共享（Key_Shared），其中在 Key_Shared 和 Shared 訂閱下可以支撐大量消費(fèi)者節(jié)點(diǎn)。其他消息流系統(tǒng)如 Kafka，因?yàn)橄M(fèi)者節(jié)點(diǎn)受限于分區(qū)個(gè)數(shù)，導(dǎo)致其在多分區(qū)時(shí)性能相對(duì)較低。（編者注：Pulsar 和 Kafka 的最新性能測(cè)評(píng)，敬請(qǐng)期待 StreamNative 即將發(fā)布的 2022 版報(bào)告）

超大 Pulsar 集群：?jiǎn)畏謪^(qū)最大消費(fèi)者數(shù)量超 8K

目前 Data 項(xiàng)目業(yè)務(wù)數(shù)據(jù)接入兩套 Pulsar 集群，分為 T-1 和 T-2。其中，T-1 對(duì)接的業(yè)務(wù)的客戶端 Pod（分為生產(chǎn)者和消費(fèi)者，且不在同一個(gè) Pod 上，部署在騰訊云容器化平臺(tái) (STKE) ，與 Pulsar 集群在相同機(jī)房；T-2 對(duì)接業(yè)務(wù)的客戶端 Pod 與 Pulsar 集群不在相同的機(jī)房（注：機(jī)房之間的數(shù)據(jù)時(shí)延相比同機(jī)房?jī)?nèi)部略高）。

Data 項(xiàng)目業(yè)務(wù)側(cè)使用 Go 語(yǔ)言開(kāi)發(fā)，接入 Pulsar 集群使用 Pulsar Go Client 社區(qū) Master 分支的最新版本。使用云梯 STKE 容器方式部署。

本文接下來(lái)將介紹 Pulsar 客戶端在多種場(chǎng)景下的性能調(diào)優(yōu)，分別針對(duì)項(xiàng)目在使用 Pulsar 的過(guò)程中遇到的客戶端生產(chǎn)超時(shí)、客戶端頻繁斷開(kāi)等情況進(jìn)行原因解析，并提供我們的解決方案，供大家參考。

客戶端性能調(diào)優(yōu)：?jiǎn)栴}與方案

在大集群下，導(dǎo)致客戶端生產(chǎn)消息耗時(shí)較長(zhǎng)或生產(chǎn)超時(shí)的原因有很多，我們先來(lái)看幾個(gè)服務(wù)器端的原因，包括：

• 消息確認(rèn)信息過(guò)大（確認(rèn)空洞）

• Pulsar-io 線程卡死

• Ledger 切換耗時(shí)過(guò)長(zhǎng)

• BookKeeper-io 單線程耗時(shí)過(guò)長(zhǎng)

• DEBUG 級(jí)別日志影響

• Topic 分區(qū)數(shù)據(jù)分布不均

接下來(lái)，針對(duì)每個(gè)可能的服務(wù)器端原因，我們逐個(gè)進(jìn)行解析。

與 Kafka、RocketMQ、TubeMQ 等不同，Apache Pulsar 不僅僅會(huì)針對(duì)每個(gè)訂閱的消費(fèi)進(jìn)度保存一個(gè)最小的確認(rèn)位置（即這個(gè)位置之前的消息都已經(jīng)被確認(rèn)已消費(fèi)），也會(huì)針對(duì)這個(gè)位置之后且已經(jīng)收到確認(rèn)響應(yīng)的消息，用 range 區(qū)間段的方式保存確認(rèn)信息。

如下圖所示：

另外，由于 Pulsar 的每個(gè)分區(qū)都會(huì)對(duì)應(yīng)一個(gè)訂閱組下的所有消費(fèi)者。Broker 向客戶端推送消息的時(shí)候，通過(guò)輪詢的方式（此處指 Shared 共享訂閱；Key_Shared 訂閱是通過(guò) key 與一個(gè)消費(fèi)者做關(guān)聯(lián)來(lái)進(jìn)行推送）給每個(gè)消費(fèi)者推送一部分消息。每個(gè)消費(fèi)者分別確認(rèn)一部分消息后，Broker 端可能會(huì)保存很多這種確認(rèn)區(qū)段信息。如下圖所示：

確認(rèn)空洞是兩個(gè)連續(xù)區(qū)間之間的點(diǎn)，用于表示確認(rèn)信息的區(qū)間段的個(gè)數(shù)。確認(rèn)空洞受相同訂閱組下消費(fèi)者個(gè)數(shù)的多少、消費(fèi)者消費(fèi)進(jìn)度的快慢等因素的影響。空洞較多或特別多即表示消費(fèi)確認(rèn)的信息非常大。

Pulsar 會(huì)周期性地將每個(gè)消費(fèi)組的確認(rèn)信息組成一個(gè) Entry，寫入到 Bookie 中進(jìn)行存儲(chǔ)，寫入流程與普通消息寫入流程一樣。因此當(dāng)消費(fèi)組的消費(fèi)確認(rèn)空洞比較多、消費(fèi)確認(rèn)信息比較大、寫入比較頻繁的時(shí)候，會(huì)對(duì)系統(tǒng)的整體響應(yīng)機(jī)制產(chǎn)生壓力，在客戶端體現(xiàn)為生產(chǎn)耗時(shí)增長(zhǎng)、生產(chǎn)超時(shí)增多、耗時(shí)毛刺明顯等現(xiàn)象。

在此情況下，可以通過(guò)減少消費(fèi)者個(gè)數(shù)、提高消費(fèi)者消費(fèi)速率、調(diào)整保存確認(rèn)信息的頻率和保存的 range 段的個(gè)數(shù)等方式處理確認(rèn)空洞。

Pulsar-io 線程池是 Pulsar Broker 端用于處理客戶端請(qǐng)求的線程池。當(dāng)這里的線程處理慢或卡住的時(shí)候，會(huì)導(dǎo)致客戶端生產(chǎn)超時(shí)、連接斷連等。Pulsar-io 線程池的問(wèn)題，可以通過(guò) jstack 信息進(jìn)行分析，在 Broker 端體現(xiàn)為存在大量的 `CLOSE_WAIT` 狀態(tài)的連接，如下圖所示：

Pulsar-io 線程池卡住的現(xiàn)象，一般為服務(wù)器端代碼 bug 導(dǎo)致，目前處理過(guò)的有：

• 部分并發(fā)場(chǎng)景產(chǎn)生的死鎖；

• 異步編程 Future 異常分支未處理結(jié)束等。

除了程序自身的 bug 外，配置也可能引起線程池卡住。如果 Pulsar-io 線程池的線程長(zhǎng)時(shí)間處于運(yùn)行狀態(tài)，在機(jī)器 CPU 資源足夠的情況下，可以通過(guò)變更 `broker.conf` 中的 `numioThreads` 參數(shù)來(lái)調(diào)整 Pulsar-io 線程池中的工作線程個(gè)數(shù)，來(lái)提高程序的并行處理性能。

注意：**Pulsar-io 線程池繁忙，本身并不會(huì)導(dǎo)致問(wèn)題。**但是，Broker 端有一個(gè)后臺(tái)線程，會(huì)周期的判斷每一個(gè) Channel（連接）有沒(méi)有在閾值時(shí)間內(nèi)收到客戶端的請(qǐng)求信息。如果沒(méi)有收到，Broker 會(huì)主動(dòng)的關(guān)閉這個(gè)連接（相反，客戶端 SDK 中也有類似的邏輯）。因此，當(dāng) Pulsar-io 線程池被卡住或者處理慢的時(shí)候，客戶端會(huì)出現(xiàn)頻繁的斷連-重聯(lián)的現(xiàn)象。

Ledger 作為 Pulsar 單個(gè)分區(qū)消息的一個(gè)邏輯組織單位，每個(gè) Ledger 下包含一定大小和數(shù)量的 Entry，而每個(gè) Entry 下會(huì)保存至少一條消息（ batch 參數(shù)開(kāi)啟后，可能是多條）。每個(gè) Ledger 在滿足一定的條件時(shí)，如包含的 Entry 數(shù)量、總的消息大小、存活的時(shí)間三個(gè)維度中的任何一個(gè)超過(guò)配置限制，都會(huì)觸發(fā) Ledger 的切換。

Ledger 切換時(shí)間耗時(shí)比較長(zhǎng)的現(xiàn)象如下：

當(dāng) Ledger 發(fā)生切換時(shí)，Broker 端新接收到或還未處理完的消息會(huì)放在 appendingQueue 隊(duì)列中，當(dāng)新的 Ledger 創(chuàng)建完成后，會(huì)繼續(xù)處理這個(gè)隊(duì)列中的數(shù)據(jù)，保證消息不丟失。

因此，當(dāng) Ledger 切換過(guò)程比較慢時(shí)會(huì)導(dǎo)致消息生產(chǎn)的耗時(shí)比較長(zhǎng)甚至超時(shí)。這個(gè)場(chǎng)景下，一般需要關(guān)注下 ZooKeeper 的性能，排查下 ZooKeeper 所在機(jī)器的性能和 ZooKeeper 進(jìn)程的 GC 狀況。

目前 Pulsar 集群中，BookKeeper 的版本要相對(duì)比較穩(wěn)定，一般通過(guò)調(diào)整相應(yīng)的客戶端線程個(gè)數(shù)、保存數(shù)據(jù)時(shí)的 E、QW、QA 等參數(shù)可以達(dá)到預(yù)期的性能。

例如，在簡(jiǎn)單的數(shù)據(jù)群里，在自建的場(chǎng)景中，對(duì)原始的日志進(jìn)行格式化如果通過(guò) Broker 的 jstack 信息發(fā)現(xiàn) BookKeeper 客戶端的 Bookkeeper-io 線程池比較繁忙時(shí)或線程池中的單個(gè)線程比較繁忙時(shí)，首先要排查 ZooKeeper、Bookie 進(jìn)程的 Full GC 情況。如果沒(méi)有問(wèn)題，可以考慮調(diào)整 Bookkeeper-io 線程池的線程個(gè)數(shù)和 Topic 的分區(qū)數(shù)。，進(jìn)行分割重新組合、類型轉(zhuǎn)換等這些操作，清洗完一個(gè)數(shù)據(jù)，再存到下一輪去。常規(guī)的做法就是需要寫代碼或者使用Logstash等開(kāi)源組件進(jìn)行ETL操作，但處理效率低，成本高，需大量配置才能處理海量數(shù)據(jù)，經(jīng)常性遇到性能問(wèn)題導(dǎo)致上有數(shù)據(jù)堆積。

在日志級(jí)別下，影響生產(chǎn)耗時(shí)的場(chǎng)景一般出現(xiàn)在 Java 客戶端。如客戶端業(yè)務(wù)引入的是 Log4j，使用的是 Log4j 的日志輸出方式，同時(shí)開(kāi)啟了 Debug 級(jí)別的日志則會(huì)對(duì) Pulsar Client SDK 的性能有一定的影響。建議使用 Pulsar Java 程序引入 Log4j 或 Log4j + SLF4J 的方式輸出日志。同時(shí)，針對(duì) Pulsar 包調(diào)整日志級(jí)別至少到 INFO 或 ERROR 級(jí)別。

在比較夸張的情況下，Debug 日志影響生產(chǎn)耗時(shí)的線程能將生產(chǎn)耗時(shí)拉長(zhǎng)到秒級(jí)別，調(diào)整后降低到正常水平（毫秒級(jí)）。具體現(xiàn)象如下：

在消息量特別大的場(chǎng)景下，服務(wù)器端的 Pulsar 集群需要關(guān)閉 Broker、Bookie 端的 Debug 級(jí)別的日志打印（建議線網(wǎng)環(huán)境），直接將日志調(diào)整至 INFO 或 ERROR 級(jí)別。

Pulsar 會(huì)在每個(gè) Namespace 級(jí)別配置 bundles ，默認(rèn) 4 個(gè)，如下圖所示。每個(gè) bundle range 范圍會(huì)與一個(gè) Broker 關(guān)聯(lián)，而每個(gè) Topic 的每個(gè)分區(qū)會(huì)經(jīng)過(guò) hash 運(yùn)算，落到對(duì)應(yīng)的 Broker 進(jìn)行生產(chǎn)和消費(fèi)。當(dāng)過(guò)多的 Topic 分區(qū)落入到相同的 Broker 上面，會(huì)導(dǎo)致這個(gè) Broker 上面的負(fù)載過(guò)高，影響消息的生產(chǎn)和消費(fèi)效率。

Data 項(xiàng)目在開(kāi)始部署的時(shí)候，每個(gè) Topic 的分區(qū)數(shù)和每個(gè) Namespace 的 bundle 數(shù)都比較少。通過(guò)調(diào)整 Topic 的分區(qū)個(gè)數(shù)和 bundle 的分割個(gè)數(shù)，使得 Topic 的分區(qū)在 Broker 上面達(dá)到逐步均衡分布的目的。

在 bundle 的動(dòng)態(tài)分割和 Topic 的分布調(diào)整上，Pulsar 還是有很大的提升空間，需要在 bundle 的分割算法（目前支持 `range_equally_divide`、`topic_count_equally_divide`，默認(rèn)目前支持 `range_equally_divide`，建議使用 `topic_count_equally_divide`）、Topic 分區(qū)的分布層面，在保證系統(tǒng)穩(wěn)定、負(fù)載均衡的情況下做進(jìn)一步的提升。

客戶端斷連/重連的原因有很多，結(jié)合騰訊 Data 項(xiàng)目場(chǎng)景，我們總結(jié)出客戶端 SDK 導(dǎo)致斷連的主要有如下幾個(gè)原因，主要包括：

• 客戶端超時(shí)斷連-重連機(jī)制

• Go SDK 的異常處理

• Go SDK 生產(chǎn)者 sequence id 處理

• 消費(fèi)者大量、頻繁的創(chuàng)建和銷毀

下面依次為大家解析這些問(wèn)題的原因與解決方案。

Pulsar 客戶端 SDK 中有與 Broker 端類似邏輯（可參考#解析2部分內(nèi)容），周期判斷是否在閾值的時(shí)間內(nèi)收到服務(wù)器端的數(shù)據(jù)，如果沒(méi)有收到則會(huì)斷開(kāi)連接。

這種現(xiàn)象，排除服務(wù)器端問(wèn)題的前提下，一般問(wèn)題出現(xiàn)在客戶端的機(jī)器資源比較少，且使用率比較高的情況，導(dǎo)致應(yīng)用程序沒(méi)有足夠的 CPU 能力處理服務(wù)器端的數(shù)據(jù)。此種情況，可以調(diào)整客戶端的業(yè)務(wù)邏輯或部署方式，進(jìn)行規(guī)避處理。

Pulsar 社區(qū)提供多語(yǔ)言的客戶端的接入能力，如支持 Java、Go、C++、Python 等。但是除了 Java 和 Go 語(yǔ)言客戶端外，其他的語(yǔ)言實(shí)現(xiàn)相對(duì)要弱一些。Go 語(yǔ)言的 SDK 相對(duì)于 Java 語(yǔ)言 SDK 還有很多地方需要完善和細(xì)化，比方說(shuō)在細(xì)節(jié)處理上與 Java 語(yǔ)言 SDK 相比還不夠細(xì)膩。

如收到服務(wù)器端的異常時(shí)，Java SDK 能夠區(qū)分哪些異常需要銷毀連接重連、哪些異常不用銷毀連接（如 `ServerError_TooManyRequests`），但 Go 客戶端會(huì)直接銷毀 Channel ，重新創(chuàng)建。

發(fā)送消息后，低版本的 Go SDK 生產(chǎn)者會(huì)收到 Broker 的響應(yīng)。如果響應(yīng)消息中的 `sequenceID` 與本端維護(hù)的隊(duì)列頭部的 `sequenceID` 不相等時(shí)會(huì)直接斷開(kāi)連接——這在部分場(chǎng)景下，會(huì)導(dǎo)致誤斷，需要區(qū)分小于和大于等于兩種場(chǎng)景。

這里描述的場(chǎng)景和解析 1-客戶端超時(shí)中的部分異常場(chǎng)景，已經(jīng)在高版本 Go SDK 中做了細(xì)化和處理，建議大家在選用 Go SDK 時(shí)盡量選用新的版本使用。目前，Pulsar Go SDK 也在快速的迭代中，歡迎感興趣的同學(xué)一起參與和貢獻(xiàn)。

集群運(yùn)維過(guò)程中在更新 Topic 的分區(qū)數(shù)后，消費(fèi)者會(huì)大量且頻繁地創(chuàng)建和銷毀。針對(duì)這個(gè)場(chǎng)景，我們已排查到是 SDK  bug 導(dǎo)致，該問(wèn)題會(huì)在 Java 2.6.2 版本出現(xiàn)。運(yùn)維期間，消費(fèi)者與 Broker 端已經(jīng)建立了穩(wěn)定的連接；運(yùn)維過(guò)程中，因業(yè)務(wù)消息量的增長(zhǎng)需求，需要調(diào)整 Topic 的分區(qū)數(shù)。客戶端在不需要重啟的前提下，感知到了服務(wù)器端的調(diào)整，開(kāi)始創(chuàng)建新增分區(qū)的消費(fèi)者，這是因?yàn)樘幚磉壿嫷?bug，會(huì)導(dǎo)致客戶端大量且頻繁地反復(fù)創(chuàng)建消費(fèi)者。如果你也遇到類似問(wèn)題，建議升級(jí) Java 客戶端的版本。

除了上面的斷連-重連場(chǎng)景外，在我們騰訊 Data 項(xiàng)目的客戶端還遇到過(guò) Pod 頻繁重啟的問(wèn)題。經(jīng)過(guò)排查和分析，我們確定是客戶端出現(xiàn)異常時(shí)，拋出 Panic 錯(cuò)誤導(dǎo)致。建議在業(yè)務(wù)實(shí)現(xiàn)時(shí)，要考慮相關(guān)的容錯(cuò)場(chǎng)景，在實(shí)現(xiàn)邏輯層面進(jìn)行一定程度的規(guī)避。

由于我們騰訊 Data 項(xiàng)目中使用的 Pulsar 集群消息量比較大，機(jī)器的負(fù)載也相對(duì)較高。涉及到 ZooKeeper，我們開(kāi)始使用的是 ZooKeeper 3.4.6 版本。在日常運(yùn)維過(guò)程中，整個(gè)集群多次觸發(fā) ZooKeeper 的一個(gè) bug，現(xiàn)象如下截圖所示：

當(dāng)前，ZooKeeper 項(xiàng)目已經(jīng)修復(fù)該 Bug，感興趣的小伙伴可以點(diǎn)擊該連接查看詳情：https://issues.apache.org/jira/browse/ZOOKEEPER-2044。因此，在 Pulsar 集群部署的時(shí)候建議打上相應(yīng)的補(bǔ)丁或升級(jí) ZooKeeper 版本。在騰訊 Data 項(xiàng)目中，我們則是選擇將 ZooKeeper 版本升級(jí)到 3.6.3 進(jìn)行了對(duì)應(yīng)處理。

小結(jié)：Pulsar 集群運(yùn)維排查指南

不同的業(yè)務(wù)有不同的場(chǎng)景和要求，接入和運(yùn)維 Apache Pulsar 集群時(shí)遇到的問(wèn)題，可能也不太一樣，但我們還是能從問(wèn)題排查角度方面做個(gè)梳理，以便找到相應(yīng)規(guī)律提升效率。

針對(duì) Apache Pulsar 集群運(yùn)維過(guò)程中遇到的問(wèn)題，如生產(chǎn)耗時(shí)長(zhǎng)、生產(chǎn)超時(shí)（timeout）、消息推送慢、消費(fèi)堆積等，如果日志中沒(méi)有什么明顯的或有價(jià)值的異常（Exception）、錯(cuò)誤（Error） 之類的信息時(shí)，可以從如下幾個(gè)方面進(jìn)行排查：

• 集群資源配置及使用現(xiàn)狀

• 客戶端消費(fèi)狀況

• 消息確認(rèn)信息

• 線程狀態(tài)

• 日志分析

下面針對(duì)每個(gè)方面做個(gè)簡(jiǎn)要說(shuō)明。

首先，需要排查進(jìn)程的資源配置是否能夠滿足當(dāng)前系統(tǒng)負(fù)載狀況。可以通過(guò) Pulsar 集群監(jiān)控儀表盤平臺(tái)查看 Broker、Bookie、ZooKeeper 的 CPU、內(nèi)存及磁盤 IO 的狀態(tài)。

其次，查看 Java 進(jìn)程的 GC 情況（特別是 Full GC 情況），處理 Full GC 頻繁的進(jìn)程。如果是資源配置方面的問(wèn)題，需要集群管理人員或者運(yùn)維人員調(diào)整集群的資源配置。

可以排查消費(fèi)能力不足引起的反壓（背壓）。出現(xiàn)背壓的現(xiàn)象一般是存在消費(fèi)者進(jìn)程，但是收不到消息或緩慢收到消息。

可以通過(guò) Pulsar 管理命令，查看受影響 Topic 的統(tǒng)計(jì)信息（stats），可重點(diǎn)關(guān)注` 未確認(rèn)消息數(shù)量數(shù)量（unackedMessages）`、`backlog 數(shù)量`和`消費(fèi)訂閱類型`，以及`處理未確認(rèn)消息（unackmessage）比較大的訂閱/消費(fèi)者`。如果未確認(rèn)消息（unackmessage）數(shù)量過(guò)多，會(huì)影響 Broker 向客戶端的消息分發(fā)推送。這類問(wèn)題一般是業(yè)務(wù)側(cè)的代碼處理有問(wèn)題，需要業(yè)務(wù)側(cè)排查是否有異常分支，沒(méi)有進(jìn)行消息的 ack 處理。

如果集群生產(chǎn)耗時(shí)比較長(zhǎng)或生產(chǎn)耗時(shí)毛刺比較多，除了系統(tǒng)資源配置方面排查外，還需要查看是否有過(guò)大的消息確認(rèn)信息。

查看是否有過(guò)大的確認(rèn)空洞信息，可以通過(guò)管理命令針對(duì)單個(gè) Topic 使用 `stats-internal` 信息，查看訂閱組中的 `individuallyDeletedMessages` 字段保存的信息大小。

消息確認(rèn)信息的保存過(guò)程與消息的保存過(guò)程是一樣的，過(guò)大的確認(rèn)信息如果頻繁下發(fā)存儲(chǔ)，則會(huì)對(duì)集群存儲(chǔ)造成壓力，進(jìn)而影響消息的生產(chǎn)耗時(shí)。

如果經(jīng)過(guò)上面的步驟，問(wèn)題還沒(méi)有分析清楚，則需要再排查下 Broker 端的線程狀態(tài)，主要關(guān)注 `pulsar-io`、`bookkeeper-io`、`bookkeeper-ml-workers-OrderedExecutor` 線程池的狀態(tài)，查看是否有線程池資源不夠或者線程池中某個(gè)線程被長(zhǎng)期占用。

可以使用 `top -p PID(具體pid) H` 命令，查看當(dāng)前 CPU 占用比較大的線程，結(jié)合 jstack 信息找到具體的線程。

如果經(jīng)過(guò)上面所述步驟仍然沒(méi)有確認(rèn)問(wèn)題來(lái)源，就需要進(jìn)一步查看日志，找到含有有價(jià)值的信息，并結(jié)合客戶端、Broker 和 Bookie 的日志及業(yè)務(wù)的使用特點(diǎn)、問(wèn)題出現(xiàn)時(shí)的場(chǎng)景、最近的操作等進(jìn)行綜合分析。

回顧與計(jì)劃

上面我們花了很大篇幅來(lái)介紹客戶端性能調(diào)優(yōu)的內(nèi)容，給到客戶端生產(chǎn)超時(shí)、頻繁斷開(kāi)與重連、ZooKeeper 等相應(yīng)的排查思路與解決方案，并匯總了常見(jiàn) Pulsar 集群?jiǎn)栴}排查指南 5 條建議，為在大消息量、多節(jié)點(diǎn)、一個(gè)訂閱里高達(dá)數(shù)千消費(fèi)者的 Pulsar 應(yīng)用場(chǎng)景運(yùn)維提供參考。

當(dāng)然，我們對(duì) Pulsar 集群的調(diào)優(yōu)不會(huì)停止，也會(huì)繼續(xù)深入并參與社區(qū)項(xiàng)目共建。

由于單個(gè) Topic 對(duì)應(yīng)的客戶端比較多，每個(gè)客戶端所在的 Pod、Client 內(nèi)部會(huì)針對(duì)每個(gè) Topic 創(chuàng)建大量的生產(chǎn)者和消費(fèi)者。由此就對(duì) Pulsar SDK 在斷連、重連、生產(chǎn)等細(xì)節(jié)的處理方面的要求比較高，對(duì)各種細(xì)節(jié)處理流程都會(huì)非常的敏感。SDK 內(nèi)部處理比較粗糙的地方會(huì)導(dǎo)致大面積的重連，進(jìn)而影響生產(chǎn)和消費(fèi)。目前，Pulsar Go SDK 在很多細(xì)節(jié)方面處理不夠細(xì)膩，與 Pulsar Java SDK 的處理有很多不一樣的地方，需要持續(xù)優(yōu)化和完善。騰訊 TEG 數(shù)據(jù)平臺(tái) MQ 團(tuán)隊(duì)也在積極參與到社區(qū)，與社區(qū)共建逐步完善 Go SDK 版本。

另外，針對(duì)騰訊 Data 項(xiàng)目的特大規(guī)模和業(yè)務(wù)特點(diǎn)，Broker 端需要處理大量的元數(shù)據(jù)信息，后續(xù) Broker 自身的配置仍需要做部分的配置和持續(xù)調(diào)整。同時(shí)，我們除了擴(kuò)容機(jī)器資源外，還計(jì)劃在 Apache Pulsar 的讀/寫線程數(shù)、Entry 緩存大小、Bookie 讀/寫 Cache 配置、Bookie 讀寫線程數(shù)等配置方面做進(jìn)一步的調(diào)優(yōu)處理。

《云原生時(shí)代的Java應(yīng)用優(yōu)化實(shí)踐》

《全面兼容Eureka：PolarisMesh(北極星)發(fā)布1.5.0版本》

掃描下方二維碼關(guān)注本公眾號(hào)，

了解更多微服務(wù)、消息隊(duì)列的相關(guān)信息！

解鎖超多鵝廠周邊！