記Kafka消費的一次生產故障處理過程
大家好，歡迎來到Tlog4J課堂，我是Jensen。
記錄今天發生的一次生產故障以及故障處理全過程。
問題背景
需求背景是這樣的：產品要求訂單過售后期后，資金平臺需要對這些訂單進行結算，并把虛擬資產入賬到下單客戶的虛擬賬戶。
因為我們是按業務領域拆分多個微服務的，為了解耦訂單與資金平臺，我們選擇了MQ異步消息的方式進行業務數據傳遞，流程簡化如下：
- 【訂單中心】查詢已過售后訂單 -> 發送MQ消息給財務中心。
- 【財務中心】接收MQ消息 -> 校驗客戶交易數據 -> 調用資金平臺結算積分。
- 【資金平臺】結算積分 -> 虛擬資產入賬。
其中，財務中心MQ消費使用了一個基于Kafka二次封裝的組件，默認通過應用內線程池異步消費消息進行業務處理（因為需要在多個地方消費），這個二開的組件也已經用了一年時間，相對較為穩定。
OK，到這一步沒有發現什么問題。
接下來，不出意外的話馬上就會發生意外。
凌晨6點觸發P1級告警，由于應用內線程池被撐爆，應用走拒絕策略737次，觸發SQL慢查詢持續10秒（剛好校驗客戶交易數據操作用到了非索引列查數據庫）。
隨后進行了問題排查，分析完生產者、消費者端的代碼，發現有以下問題：
- 消費端財務中心對應的消費方法使用了默認的異步方式處理消息，線程數大小用了默認的200個線程，如果短時間內接收多條MQ而又無法快速執行完釋放線程，線程數達到200個必然會走拒絕策略報錯，甚至影響其它異步執行MQ的消費者方法（共用了同一個線程池）。
- 訂單中心同一時刻批量修改已過售后訂單，把發送MQ的方法包在了for循環中。這意味著如果同一時刻發送大量MQ消息，又因為第一條消費者存在的隱患，將導致發送的MQ消息無法被正常消費。
處理過程
分析完問題，基本上能確定如何解決了，分三步：
第一步：對于線上消費異常的數據，按照代碼邏輯重新跑SQL修復相應數據。這件事需要第一時間做，不能因為程序的問題影響客戶體驗。
第二步：該MQ組件異步消費的消息堆積能力受線程池大小影響，應該把消息堆積的問題交給專業的MQ自己負責，所以暫時關掉該Topic的異步執行，不用線程池，改為同步。后續對該MQ組件進行優化，不再提供異步執行方式，如使用類似@KafkaListener(topic = "xxx", groupId = "
appName.beanName.methodName")的方式，只不過需要動態創建KafkaListener，利用MQ本身消費者組的功能，避免消息堆積在應用線程池內。
第三步：通過業務規避，合理評估需求，對于已經確定的場景，能合并的MQ請求、SQL請求、Feign接口調用請求，比如上面提到的for循環發送訂單已過售后通知、校驗客戶交易數據、資金平臺積分入賬場景，把它們識別出來，通過批量合并請求的方式解決頻繁請求可能發生的問題（以空間換頻率）。請求合并后還需要評估合并請求的大小限制，進一步進行請求切割，比如訂單合并后有10萬條數據，放在一個請求里也不合理，應該按照一定的訂單量切割后再發送請求。
這里分享一個領導（技術總監）用了8年的需求分析方法：
總結一下
對于此類生產問題，分三步解決：
- 第一，第一時間修復生產數據，避免影響客戶體驗。
- 第二，找出臨時解決方案——找出問題根因針對性解決。
- 第三，長遠的問題規避方案——合理評估需求。
