8月總票房已突破10億！《封神》第一：口碑已經成了
8月5日消息，據燈塔專業版數據，截至8月5日9時35分，8月總票房（含預售）已突破10億。其中，《封神》以大比分的優勢領先。根據官方消息，目前該片總票房已經超過14.
前兩天收到業務反饋有一個 topic 的分區消息堆積了：
圖片
根據之前的經驗來看，要么是業務消費邏輯出現問題導致消費過慢，當然也有小概率是消息隊列的 Bug（我們使用的是 pulsar）。
圖片
通過排查，發現確實是在一點多的時候消息堆積了（后面是修復之后堆積開始下降）。
于是我在剛才堆積處查看了一條堆積消息的列表：
圖片
獲取到其中一條消息的 messageId.
這里本質上使用的是 pulsar-admin 的 API。org.apache.pulsar.client.admin.Topics#peekMessages
圖片
再通過這條消息的 id （為了演示，這里的 messageId 可能不一樣）在我們的 pulsar 消息鏈路系統中找到了消息的發送鏈路：
圖片
通過這個鏈路會發現消息一直在推送，但就是沒有收到客戶端的 ACK 響應。
相關的消息鏈路埋點可以參考這里：如何編寫一個 Pulsar Broker Interceptor 插件
簡單來說就是在以下幾個 broker 提供的攔截器接口加上埋點數據即可：
既然知道了是客戶端沒有響應 ACK，那就得知道客戶端此時在干什么。
首先排查了 JVM 內存、CPU 等監控情況，發現一切都挺正常的，這段時間沒有明顯的尖刺。
于是便準備使用 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 的功能，避免直接登錄到服務器進行操作。
圖片
圖片
我們在研效普通也內置了該功能，讓開發排查問題更加方便。
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 debugupdate 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 的用法可以參考官網。
參考鏈接：
本文鏈接：http://www.tebozhan.com/showinfo-26-86685-0.html深入剖析：如何使用Pulsar和Arthas高效排查消息隊列延遲問題
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 一種避免寫大量CRUD方法的新思路
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號