深入剖析：如何使用Pulsar和Arthas高效排查消息隊列延遲問題
背景
前兩天收到業務反饋有一個 topic 的分區消息堆積了：
圖片
根據之前的經驗來看，要么是業務消費邏輯出現問題導致消費過慢，當然也有小概率是消息隊列的 Bug（我們使用的是 pulsar）。
排查
圖片
通過排查，發現確實是在一點多的時候消息堆積了（后面是修復之后堆積開始下降）。
于是我在剛才堆積處查看了一條堆積消息的列表：
圖片
獲取到其中一條消息的 messageId.
這里本質上使用的是 pulsar-admin 的 API。org.apache.pulsar.client.admin.Topics#peekMessages
圖片
再通過這條消息的 id （為了演示，這里的 messageId 可能不一樣）在我們的 pulsar 消息鏈路系統中找到了消息的發送鏈路：
圖片
通過這個鏈路會發現消息一直在推送，但就是沒有收到客戶端的 ACK 響應。
相關的消息鏈路埋點可以參考這里：如何編寫一個 Pulsar Broker Interceptor 插件
簡單來說就是在以下幾個 broker 提供的攔截器接口加上埋點數據即可：
- messageProduced
- messageDispatched
- messageAcked
既然知道了是客戶端沒有響應 ACK，那就得知道客戶端此時在干什么。
首先排查了 JVM 內存、CPU 等監控情況，發現一切都挺正常的，這段時間沒有明顯的尖刺。
Arthas 排查
于是便準備使用 arthas 查看下線程的運行情況。
我們進入到對應 Pod 的容器，執行：
java -jar arthas-boot.jar因為 JVM 內存都沒有啥異常，所以先看看 thread 的運行堆棧，考慮到是 pulsar 消費線程卡住了，所以我們需要加上線程狀態已經過濾下線程的名稱：
圖片
thread --state WAITING | grep pulsar此時就會列出當前 Java 進程中狀態為 WATING 并且線程名稱以 pulsar 開頭的線程。
我在之前的文章 從 Pulsar Client 的原理到它的監控面板 中分析過客戶端的原理。
圖片
圖片
可以知道 pulsar 客戶端在其中使用的是 pulsar-打頭的線程名稱，所以這樣就列出了我們需要重點關注的線程。
我們以圖中列出的線程 Id：320 為例：
thread 320
圖片
此時便會打印當前線程的堆棧。
從上述堆棧中會發現線程一直處于 IO 操作中，看起來是在操作數據庫。
我們再往下翻一翻，會發現上層調用的業務代碼：
圖片
查閱代碼得知這是一個數據庫的寫入操作，看起來是在這個環節數據庫響應過慢導致的 pulsar 線程被阻塞了；從而導致消息沒有及時 ACK。
為了最終確認是否由數據庫引起的，于是繼續查詢了當前應用的慢 SQL 情況：
圖片
發現其中有一個查詢語句調用頻次和平均耗時都比較高，而且正好這個表也是剛才在堆棧里操作的那張表。
經過業務排查發現這個慢 SQL 是由一個定時任務觸發的，而這個定時任務由于某些原因一直也沒有停止，所以為了快速解決這個問題，我們先嘗試將這個定時任務停掉。
果然停掉沒多久后消息就開始快速消費了：
圖片
從這個時間線也可以看得出來了，在服務端推送了多次之后終于收到了 ACK。
修復之后業務再去排查優化這個慢 SQL，這樣這個問題就得到根本的解決了。
更多好用技巧
當然 arthas 好用的功能還遠不止此，我覺得還有以下功能比較好用：
火焰圖
profile：可以輸出火焰圖，在做性能分析的時候非常有用。
圖片
動態修改內存數據
還記得之前我們碰到過一個 pulsar 刪除 topic 的 Bug，雖然最終修復了問題，但是在發布修復版本的時候為了避免再次觸發老版本的 bug，需要在內存中將某個關鍵字段的值修改掉。
而且是不能重啟應用的情況下修改，此時使用 arthas 就非常的方便：
curl -O https://arthas.aliyun.com/arthas-boot.jar && java -jar arthas-boot.jar 1 -c "vmtool -x 3 --action getInstances --className org.apache.pulsar.broker.ServiceConfiguration --express 'instances[0].setTopicLevelPoliciesEnabled(false)'"這里使用的是 vmtool 這個子命令來獲取對象，最終再使用 express 表達式將其中的值改為了 false。
當然這是一個高危操作，不到萬不得已不推薦這么使用。
Arthas Tunnel & Web Console
這是一個方便開發者通過網頁就可以連接到 arthas 的功能，避免直接登錄到服務器進行操作。
圖片
圖片
我們在研效普通也內置了該功能，讓開發排查問題更加方便。
CPU 使用過多
cpu 異常使用排查也是一個非常有用的功能，雖然我們可以通過監控得知 JVM 的 cpu 使用情況，但是沒法知道具體是哪個線程以及哪行代碼造成的 cpu 過高。
thread -n 3
圖片
使用以上命令就可以將 cpu 排名前三的線程打印出來，并且列出他的堆棧情況，這樣可以很直觀的得知 cpu 消耗了在哪些地方了。
當然還有一些 trace 查詢：
trace demo.MathGame run '#cost > 10'比如這是將調用超過 10ms 的函數打印出來，不過如果我們接入了可觀測系統（OpenTelemetry、skywalking等）這個功能就用不太上了。
還可以在運行的時候不停機修改日志級別，這種在線上排查一些疑難雜癥的時候非常好用（通常情況下 debug 日志是不打印的），我們可以將日志級別調整為 debug 打印出更加詳細的信息：
[arthas@2062]$ logger --name ROOT --level debug
update logger level success.如果是在 kubernetes 環境中執行也有可能碰到 Java 進程啟動后沒有在磁盤中寫入 PID 的情況：
$ java -jar arthas-boot.jar
[INFO] arthas-boot version: 3.6.7
[INFO] Can not find java process. Try to pass <pid> in command line.
Please select an available pid.導致直接運行的時候無法找到 Java 進程；此時就需要先 ps 拿到 PID 之后再傳入 PID 連入 arthas：
$ java -jar arthas-boot.jar 1更多關于 arthas 的用法可以參考官網。
參考鏈接：
- https://pulsar.apache.org/docs/3.2.x/admin-api-topics/#peek-messages
- https://crossoverjie.top/2023/12/11/ob/Pulsar-Broker-Interceptor/
- https://arthas.aliyun.com/
- https://crossoverjie.top/2024/01/09/ob/Pulsar-Delete-Topic/
