現象

生產中kafka叢集一臺伺服器硬體故障下線，kafka叢集具備高可用特性，下線broker上的leader分割槽自動切換到新的broker節點，客戶端連結隨之切換至新的節點繼續提供服務，從流量上看也未發現異常情況；叢集整體執行平穩，無異常。但後續有一個業務方反饋每10分鐘就有少量介面響應時間升高導致超時，檢視日誌發現傳送訊息的介面有WARN日誌，日誌內容如下：

分析

根據服務日誌異常呼叫棧反映出的問題：業務執行緒在訊息傳送時，會觸發獲取遠端metadata的服務請求，請求發到了宕機伺服器後丟擲Exception，並且很有周期性的每10分鐘間隔發生少量異常；根據呼叫棧深入到kafka程式碼，找到發生問題的位置DefaultEventHandler.handle()：

紅色方框裡的程式碼，是傳送訊息前處理的一段邏輯，topicMetadataRefreshInterval為更新metadata路由表的間隔時間，預設為600000(10分鐘)。

傳送訊息前會判斷本次傳送是否需要更新路由表，判斷依據為topicMetadataRefreshInterval指定的時間間隔, 設定不同值時執行情況如下：

topicMetadataRefreshInterval< 0 時：

         會跳過路由表更新邏輯，直接進入到訊息傳送環節（下圖紅色方框部分），如果傳送不成功(比如partition leader切換情況)，則返回結果列表outstandingProduceRequests不為空，執行緒會睡眠retryBackoffMs指定的時間，然後同步傳送brokerPartitionInfo.updateInfo()

topicMetadataRefreshInterval= 0 時：

         該情況下，每次傳送訊息前都會進入到路由表更新邏輯執行brokerPartitionInfo.updateInfo(…)

topicMetadataRefreshInterval> 0 時：

         該情況會按照topicMetadataRefreshInterval(預設值為10分鐘)

上面文字描述了訊息傳送階段，在什麼條件下會執行brokerPartitionInfo.updateInfo(…)這段邏輯，而引起執行緒堵塞的真正凶手也將浮出水面，updateInfo()內部有段邏輯才是引起延遲的真凶fetchTopicMetadata()：

fetchTopicMetadata方法裡，對broker列表首先做了混洗處理，然後從列表第一個broker進行遍歷並執行同步傳送metadata request請求，如果發向第一個broker獲取meta失敗，繼續第二個直到成功或者列表遍歷完畢退出；在生產案例中，一臺broker宕機(整臺機器斷電)，如果請求的正好是該機器，建立TCP握手階段會出現堵塞，直到socket的connection timeout超時返回，會造成業務執行緒堵塞；有個細節還需說明，如果機器存活程序死掉的情況下，該堵塞時間會小很多，原因TCP握手成功，訪問服務程序失敗會立即返回錯誤並切換下一個broker嘗試；我們遇到的情況正好是IP不可訪問，因而引起較長的超時等待，從而導致業務介面超時，但訊息成功傳送；

在發現kafka客戶端有這樣的行為後，為了防止影響，臨時使用一臺非標準配置的機器快速加入kafka叢集解決問題（當時機房沒有kafka標準配置的機器）。

方案

針對以上情況，相關改進措施：

      1.   使用同步傳送情況下，修改topic.metadata.refresh.interval.ms 值為負數；

             a. 客戶端只有在傳送失敗的情況下(比如leader節點發生變化的分割槽)才會進行一次路由更新，不會對正常的傳送連結產生影響；

             b. 發生路由更新會出現請求時間加長的情況，成功之後不會對後續傳送產生影響；

             c. 但在partition數量擴容時，客戶端正常傳送情況下，缺乏感知分割槽變化進行動態調整；

      2.   在kafka最新java客戶端中，採用了新的執行緒模型，即使在同步傳送模式下也會採用非同步執行緒來執行訊息的傳送，更新metadata的動作不會在業務執行緒中執行,而是非同步sender執行緒來執行，並會跳過對失效節點的請求，避免網路問題引起執行緒的堵塞，同時介面層面採用了友好的超時中斷機制，讓業務更好的控制超時情況。