性能調優篇：困擾我半年之久的RocketMQ timeout exception 終于破解了

在內網環境中，超時問題，網路表示這個鍋我不背，

筆者對于超時的理解，隨著在作業中不斷實踐，其理解也越來越深刻，RocketMQ在生產環境遇到的超時問題，已經困擾了我將近半年，現在終于取得了比較好的成果，和大家來做一個分享，

本次技術分享，由于涉及到網路等諸多筆者不太熟悉的領域，如果存在錯誤，請大家及時糾正，實作共同成長與進步，

1、網路超時現象

時不時總是接到專案組反饋說生產環境MQ發送超時，客戶端相關的日志截圖如下：

今天的故事將從張圖開始，

2、問題排查

2.1 初步分析

上圖中有兩條非常關鍵日志：

• invokeSync：wait response timeout exception
  網路呼叫超時

• recive response,but not matched any request

  這條日志非常之關鍵，表示盡管客戶端在獲取服務端回傳結果時超時了，但客戶端最侄訓是能收到服務端的回應結果，只是此時客戶端已經等待足夠時間后放棄處理了，

關于第二條日志，我再詳細闡述一下其運作機制，其實也是用一條鏈接發送多個請求的編程套路，一條長連接，向服務端先后發送2個請求，客戶端在收到服務端回應結果時，怎么判斷這個回應結果對應的是哪個請求呢？如下圖所示：

客戶端多個執行緒，通過一條連接發送了req1,req2兩個請求，但在服務端通常都是多執行緒處理，回傳結果時可能會先收到req2的回應，那客戶端如何識別服務端回傳的資料是對應哪個請求的呢？

解決辦法是客戶端在發送請求之前，會為該請求生成一個本機器唯一的請求id(requestId)，并且會采用Future模式，將requestId與Future物件放入一個Map中，然后將reqestId放入請求體中，服務端在回傳回應結果時將請求ID原封不動的放入到回應結果中，當客戶端收到回應時，先界面出requestId，然后從快取中找到對應的Future物件，喚醒業務執行緒，將回傳結構通知給呼叫方，完成整個通信，

故從這里能看到，客戶端在指定時間內沒有收到服務端的請求，但最侄訓是能收到，矛頭直接指向Broker端，是不是Broker有瓶頸，處理很慢導致的，

2.2 Broker端處理瓶頸分析

在我的“經驗”中，RocketMQ訊息發送如果出現瓶頸，通常會回傳各種各樣的Broker Busy，而且可以通過跟蹤Broker端寫入PageCache的資料指標來判斷Broker是否遇到了瓶頸，

grep "PAGECACHERT" store.log

得到的結果類似如下截圖：

溫馨提示:上圖是我本機中的截圖，當時分析問題的時候，MQ集群中各個Broker中這些資料，寫入PageCache的時間沒有超過100ms的，

正是由于良好的pagecache寫入資料，根據如下粗糙的網路互動特性，我提出將矛盾點轉移到網路方面：

并且我還和業務方確定，雖然訊息發送回傳超時，但訊息是被持久化到MQ中的，消費端也能正常消費，網路組同事雖然從理論上來說局域網不會有什么問題，但鑒于上述現象，網路組還是開啟了網路方面的排查，

溫馨提示：最后證明是被我帶偏了，

2.3 網路分析

通常網路分析有兩種手段，netstat 與網路抓包，

2.3.1 netstat查看Recv-Q與Send-Q

我們可以通過netstat重點觀察兩個指標Recv-Q、Send-Q，

• Recv-Q
  tcp通道的接受快取區

• Send-Q

  tcp通道的發送快取區

在TCP中，Recv-Q與Send-Q的作用如下圖所示：

• 客戶端呼叫網路通道，例如NIO的Channel寫入資料，資料首先是寫入到TCP的發送快取區，如果發送發送區已滿，客戶端無法繼續向該通道發送請求，從NIO層面呼叫Channel底層的write方法，會回傳0，表示發送緩沖區已滿，需要注冊寫事件，待發送快取區有空閑時再通知上層應用程式可以發訊息，
• 資料進入到發送快取區后，接下來資料會隨網路到達目標端，首先進入的是目標端的接收快取區，如果與NIO掛鉤的化，通道的讀事件會繼續，應用從接收快取區中成功讀取到位元組后，會發送ACK給發送方，
• 發送方在收到ACK后，會洗掉發送緩沖區中的資料，如果接收方一直不讀取資料，那發送方也無法發送資料，

網路同事分布在客戶端、MQ服務器上通過每500ms采集一次netstat ，經過對采集結果進行匯總，出現如下圖所示：

從客戶端來看，客戶端的Recv-Q中會出現大量積壓，對應的是MQ的Send-Q中出現大量積壓，

從上面的通訊模型來看，再次推斷是否是因為客戶端從網路中讀取位元組太慢導致的，因為客戶端為虛擬機，從netstat 結果來看，疑似是客戶端的問題(備注，其實最后并不是客戶端的問題，請別走神)，

2.3.2 網路轉包

網路組同事為了更加嚴謹，還發現了如下的包：

這里有一個問題非常值得懷疑，就是客戶端與服務端的滑動視窗只有190個位元組，一個MQ訊息發送回傳包大概有250個位元組左右，這樣會已回應包需要傳輸兩次才能被接收，一開始以為這里是主要原因，但通過其他對比，發現不是滑動視窗大于250的客戶端也存在超時，從而判斷這個不是主要原因，后面網路同事利用各種工具得出結論，網路不存在問題，是應用方面的問題，

想想也是，畢竟是局域網，那接下來我們根據netstat的結果，將目光放到了客戶端的讀性能上，

2.4 客戶端網路讀性能瓶頸分析

為此，我為了證明讀寫方面的性能，我修改了RocketMQ CLient相關的包，加入了Netty性能采集方面的代碼，其代碼截圖如下：

我的主要思路是判斷客戶端對于一個通道，每一次讀事件觸發，一個通道會進行多少次讀取操作，如果一次讀事件觸發，需要觸發很多次的讀取，說明一個通道中確實積壓了很多資料，網路讀存在瓶頸，

但令人失望的是客戶端的網路讀并不存在瓶頸，部分采集資料如下所示：

通過awk命令對其進行分析，發現一次讀事件觸發，大部分通道讀兩次即可將讀快取區中的資料抽取成功，讀方面并不存在瓶頸，對awk執行的統計分析如下圖所示：

那矛頭又將指向Broker，是不是寫到快取區中比較慢呢？

2.5 Broker端網路層面瓶頸

經過上面的分析，Broker服務端寫入pagecache很快，維度將回應結果寫入網路這個環節并未監控，是不是寫入回應結果并不及時，大量積壓在Netty的寫快取區，從而導致并未及時寫入到TCP的發送緩沖區，從而造成超時，

筆者本來想也對其代碼進行改造，從Netty層面去監控服務端的寫性能，但考慮到風險較大，暫時沒有去修改代碼，而是再次認真讀取了RocketMQ封裝Netty的代碼，在此次讀取原始碼之前，我一直以為RocketMQ的網路層基本不需要進行引數優化，因為公司的服務器都是64核心的，而Netty的IO執行緒默認都是CPU的核數，但在閱讀原始碼發現，在RocketMQ中與IO相關的執行緒引數有如下兩個：

• serverSelectorThreads
  默認值為3，
• serverWorkerThreads
  默認值為8，

serverSelectorThreads，在Netty中，就是WorkGroup，即所謂的IO執行緒池，每一個執行緒池會持有一個NIO中的Selector物件用來進行事件選擇，所有的通道會輪流注冊在這3個執行緒中，系結在一個執行緒中的所有Channel，會串行進行讀寫操作，即所有通道從TCP讀快取區，將資料寫到發送快取區都在這個執行緒中執行，

我們的MQ服務器的配置，CPU的核屬都在64C及以上，用3個執行緒來做這個事情，顯然有點太“小家子氣”，該引數可以調優，

serverWorkerThreads，在Netty的執行緒模型中，默認情況下事件的傳播(編碼、解碼)都在IO執行緒中，即在上文中提到的Selector物件所在的執行緒，為了降低IO執行緒的壓力，RocketMQ單獨定義一個執行緒池，用于事件的傳播，即IO執行緒只負責網路讀、寫，讀取的資料進行解碼、寫入的資料進行編碼等操作，單獨放在一個獨立的執行緒池，執行緒池執行緒數量由serverWorkerThreads指定，

看到這里，終于讓我心潮澎湃，感覺離真相越來越近了，參考Netty將IO執行緒設定為CPU核數的兩倍，我第一波引數優化設定為serverSelectorThreads=16，serverWorkerThreads=32，在生產環境進行一波驗證，

經過1個多月的驗證，在集群機器數量減少(雙十一之后縮容)，只出現過極少數的訊息發送超時，基本可以忽略不計，

溫馨提示：關于Netty執行緒模型的詳解，可以參考 圖解Netty執行緒模型

3、總結

本文詳細介紹了筆者排查MQ發送超時的精力，最終定位到的是RocketMQ服務端關于網路通信執行緒模型引數設定不合理，

之所以耗費這么長時間，其實有值得反思的地方，我被我的“經驗”誤導了，其實以前我對超時的原因直接歸根于網路，理由是RocketMQ的寫入PageCache資料非常好，基本都沒有超過100ms的寫入請求，以為RocketMQ服務端沒有性能瓶頸，并沒有從整個網路通信層考慮，

好了，本文就介紹到這里了，一鍵三連(關注、點贊、留言)是對我最大的鼓勵，

掌握一到兩門java主流中間件，是敲開BAT等大廠必備的技能，送給大家一個Java中間件學習路線，助力大家實作職場的蛻變，

Java進階之梯，成長路線與學習資料，助力突破中間件領域

最后分享筆者一個硬核的RocketMQ電子書，您將獲得千億級訊息流轉的運維經驗，

獲取方式：RocketMQ電子書，