導(dǎo)語

近期，騰訊 TEG 數(shù)據(jù)平部 MQ 團隊開發(fā)部署了一套底層運維指標性能分析系統(tǒng)（本文簡稱 Data 項目） ，目前作為通用基礎(chǔ)設(shè)施服務(wù)整個騰訊集團。該系統(tǒng)旨在收集性能指標、上報數(shù)據(jù)以用于業(yè)務(wù)的運維監(jiān)控，后續(xù)也將延用至前后端實時分析場景。

騰訊 Data 項目選用 Apache Pulsar 作為消息系統(tǒng)，其服務(wù)端采用 CVM 服務(wù)器（Cloud Virtual machine，CVM）部署，并將生產(chǎn)者和消費者部署在 Kube.NETes 上，該項目 Pulsar 集群是騰訊數(shù)據(jù)平臺部 MQ 團隊接入的消息量最大的 Pulsar 集群。在整個項目中，我們在 Apache Pulsar 大規(guī)模集群運維過程中遇到了一些問題和挑戰(zhàn)。本文將對這些問題展開描述分析，并分享對應(yīng)處理方案，同時也會解析涉及到的相關(guān) Apache Pulsar 設(shè)計原理。

希望本文能夠?qū)γ媾R同類場景的用戶與開發(fā)者提供參考。

作者簡介

鮑明宇

騰訊高級軟件工程師

目前就職于騰訊 TEG 數(shù)據(jù)平臺部， 負責(zé) Apache Pulsar、Apache Inlong、DB 數(shù)據(jù)采集等項目的開發(fā)工作。目前專注于大數(shù)據(jù)領(lǐng)域，消息中間件、大數(shù)據(jù)數(shù)據(jù)接入等方向，擁有 10 年 JAVA 相關(guān)開發(fā)經(jīng)驗。

張大偉

騰訊高級軟件工程師

Apache Pulsar Committer， 目前就職于騰訊 TEG 數(shù)據(jù)平臺部， 主要負責(zé) Apache Pulsar 項目相關(guān)工作。目前專注于 MQ 和數(shù)據(jù)實時處理等領(lǐng)域，擁有 6 年大數(shù)據(jù)平臺相關(guān)開發(fā)經(jīng)驗。

業(yè)務(wù)消息量大，對生產(chǎn)與消費耗時指標敏感

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

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

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

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

超大 Pulsar 集群：單分區(qū)最大消費者數(shù)量超 8K

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

服務(wù)器側(cè)相關(guān)參數(shù)

業(yè)務(wù)側(cè)相關(guān)參數(shù)

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

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

客戶端性能調(diào)優(yōu)：問題與方案

調(diào)優(yōu)一：客戶端生產(chǎn)超時，服務(wù)器端排查

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

• 消息確認信息過大（確認空洞）
• Pulsar-io 線程卡死
• Ledger 切換耗時過長
• BookKeeper-io 單線程耗時過長
• DEBUG 級別日志影響
• Topic 分區(qū)數(shù)據(jù)分布不均

接下來，針對每個可能的服務(wù)器端原因，我們逐個進行解析。

解析 1：消費確認信息過大（確認空洞）

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

如下圖所示：

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

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

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

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

解析 2：Pulsar-io 線程卡死

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

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

• 部分并發(fā)場景產(chǎn)生的死鎖；
• 異步編程 Future 異常分支未處理結(jié)束等。

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

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

解析 3：Ledger 切換耗時過長

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

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

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

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

解析 4：BookKeeper-io 單線程耗時過長面對疫情 不必恐慌

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

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

解析 5：Debug 級別日志影響

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

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

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

解析 6：Topic 分區(qū)分布不均

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

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

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

調(diào)優(yōu)二：客戶端頻繁斷開與重連

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

• 客戶端超時斷連-重連機制
• Go SDK 的異常處理
• Go SDK 生產(chǎn)者 sequence id 處理
• 消費者大量、頻繁的創(chuàng)建和銷毀

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

解析 1：客戶端超時斷連-重連機制

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

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

解析 2：Go SDK 的異常處理

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

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

解析 3：Go SDK 生產(chǎn)者 Sequence id 處理

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

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

解析 4：消費者大量且頻繁地創(chuàng)建和銷毀

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

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

調(diào)優(yōu)三：升級 ZooKeeper

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

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

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

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

針對 Apache Pulsar 集群運維過程中遇到的問題，如生產(chǎn)耗時長、生產(chǎn)超時（timeout）、消息推送慢、消費堆積等，如果日志中沒有什么明顯的或有價值的異常（Exception）、錯誤（Error） 之類的信息時，可以從如下幾個方面進行排查：

• 集群資源配置及使用現(xiàn)狀
• 客戶端消費狀況
• 消息確認信息
• 線程狀態(tài)
• 日志分析

下面針對每個方面做個簡要說明。

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

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

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

2. 客戶端消費狀況

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

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

3. 消息確認信息

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

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

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

4. 線程狀態(tài)

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

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

5. 日志分析

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

回顧與計劃

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

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

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

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