掌握一到兩門java主流中間件，是敲開BAT等大廠必備的技能，送給大家一個Java中間件學習路線，助力大家實作職場的蛻變，
Java進階之梯，成長路線與學習資料，助力突破中間件領域
在訊息發送端遇到性能瓶頸時是否有辦法正確的評估瓶頸在哪呢？如何針對性的進行調優呢？
1、Kafka 訊息發送端監控指標
其實Kafka早就為我們考慮好了，Kafka提供了豐富的監控指標，并提供了JMX的方式來獲取這些監控指標，在客戶端提供的監控指標如下圖所示：
主要的監控指標分類如下：
- producer-metrics
訊息發送端的監控指標，其子節點為該行程下所有的生產者 - producer-node-metrics
以Broker節點為維度，每一個發送方的資料指標， - producer-topic-metrics
以topic為維度，統計該發送端的一些指標，
Kafka Producer相關的指標比較多，本文不會一一羅列，
1.1 producer-metrics
producer-metrics是發送端一個非常重要的監控項，如下圖所示：
其重點項說明如下：
-
batch-size-avg
Sender執行緒實際發送訊息時一個批次(ProducerBatch)的平均大小， -
batch-size-max
Sender執行緒時間發送訊息時一個批次的最大大小，實踐指導：個人覺得這兩個引數非常有必要進行采集，如果該值遠小于batch.size設定的值，如果吞吐量不達預期，可以適當調大linger.ms，
-
batch-split-rate
Kafka提供了對大的ProducerBatch分割成小的機制，即如果客戶端的ProducerBatch如果超過了服務端允許的最大訊息大小，將會觸發在客戶端分割重新發送，該值記錄每秒切割的速率 -
batch-split-total
Kafka 發生的 split 次數，溫馨提示：按照筆者對這部分原始碼的閱讀，我覺得ProducerBatch的split的意義不大，因為新分配的ProducerBatch的容量會等于batch.size，未超過該大小，則該Batch不會被分隔，筆者認為該功能大概率無法完成實際的切割意圖，
實踐指導：如果該值不為0，則表示服務端，客戶端設定的訊息大小不合理，客戶端設定的batch.szie大小應該小于服務端設定的 max.message.bytes，默認值100W位元組(約等于1M)
-
buffer-available-bytes
當前發送端快取區可用位元組大小， -
buffer-total-bytes
發送端總的快取區大小，默認為32M，33,554,432個位元組，實戰指導：如果快取區剩余位元組數持續較低，需要評估快取區大小是否合適，Sender執行緒遇到了瓶頸，從而考慮網路、Brorker是否遇到瓶頸，
-
bufferpool-wait-ratio
-
bufferpool-wait-time-total
客戶端從快取區中申請記憶體用于創建ProducerBatch所阻塞的總時長，實戰指導：如果該值持續大于0，說明發送存在瓶頸，可以適當降低linger.ms的值，讓訊息有機會得到更加及時的處理，
-
produce-throttle-time-avg
訊息發送被broker限流的平均時間 -
produce-throttle-time-max
訊息發送被broker限流的最大時間 -
io-ratio
IO執行緒處理IO讀寫的總時間 -
io-time-ns-avg
每一次事件選擇器呼叫IO操作的平均時間(單位為納秒) -
io-waittime-total
io執行緒等待讀寫就緒的平均時間（單位為納秒） -
iotime-total
io處理總時間， -
network-io-rate
客戶端每秒所有連接的網路讀寫tps， -
network-io-total
客戶端所有連接上的網路操作(讀或寫)總數，
1.2 通用指標
Kafka在訊息發送端除了上述指標外，還有一些通用類的監控指標，這類指標的統計維度包括：訊息發送者、節點、TOPIC三個維度，
主要的維度說明如下：
- producer-metics
發送端維度 - producer-node-metrics
發送端-Broker節點維度 - producer-topic-metrics
發送端-主題維度的統計
接下來說明的指標，分別以不同的維度進行統計，但其表示的含義表示一樣，故接下來統一說明，
-
incoming-byte-rate
每秒的入端流量，每秒進入的位元組數， -
incoming-byte-total
總共進入的位元組數， -
outgoing-byte-total
總出發送的位元組數， -
request-latency-avg
訊息發送的平均延時， -
request-latency-max
訊息發送的最大延遲時間，
實戰指導：latency-avg與max可以反應訊息發送的延遲性能，如果延遲過高，說明Sender執行緒發送訊息存在瓶頸，建議該值與linger.ms進行比較，如果該值顯著小于linger.ms，則為了提高吞吐率，可適當調整batch.size的大小，
-
request-rate
每秒發送Tps -
request-size-avg
訊息發送的平均大小， -
request-size-max
Sender執行緒單次訊息發送的最大大小，實戰指導：如果該值遲遲小于max.request.size，說明客戶端訊息積壓的訊息不多，如果從其他維度表明遇到了瓶頸，可以適當linger.ms，batch.size，可有效提高吞吐，
-
request-total
請求發送的總位元組數 -
response-rate
每秒接受服務端回應TPS -
response-total
收到服務端回應總數量，
2、監控指標采集
雖然Kafka內置了眾多的監控指標，但這些指標默認是存盤在記憶體中，既然是存放在記憶體中，為了避免監控資料無休止的增加記憶體觸發記憶體溢位，通常監控資料的存盤基本是基于滑動視窗，即只會存盤最近一段時間內的監控資料，進行滾動覆寫，
故為了更加直觀的展示這些指標，因為需要定時將這些資訊進行采集，統一存盤在其他資料庫等持久化存盤，可以根據歷史資料繪制曲線，希望實作的效果如下圖所示：
基本的監控采集系統架構設計如下圖所示：
mq-collect應該是放在生產者SDK中，通過mq-collect類別庫異步定時將采集資訊上傳的到時序資料庫InfluxDB,然后通過mq-portal門戶展示頁面，對每一個生產客戶端按指標進行可視化展示，實作監控資料的可視化，從而為性能優化提供依據，
好了，本文就介紹到這里了，一鍵三連(關注、點贊、留言)是對我最大的鼓勵，
掌握一到兩門java主流中間件，是敲開BAT等大廠必備的技能，送給大家一個Java中間件學習路線，助力大家實作職場的蛻變，
Java進階之梯，成長路線與學習資料，助力突破中間件領域
最后分享筆者一個硬核的RocketMQ電子書，您將獲得千億級訊息流轉的運維經驗，
獲取方式：私信回復RMQPDF即可獲取，
個人網站：https://www.codingw.net
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/286426.html
標籤：其他