大家好，歡迎來(lái)到Tlog4J課堂，我是Jensen。

記錄今天發(fā)生的一次生產(chǎn)故障以及故障處理全過(guò)程。

問(wèn)題背景

需求背景是這樣的：產(chǎn)品要求訂單過(guò)售后期后，資金平臺(tái)需要對(duì)這些訂單進(jìn)行結(jié)算，并把虛擬資產(chǎn)入賬到下單客戶的虛擬賬戶。

因?yàn)槲覀兪前礃I(yè)務(wù)領(lǐng)域拆分多個(gè)微服務(wù)的，為了解耦訂單與資金平臺(tái)，我們選擇了MQ異步消息的方式進(jìn)行業(yè)務(wù)數(shù)據(jù)傳遞，流程簡(jiǎn)化如下：

1. 【訂單中心】查詢已過(guò)售后訂單 -> 發(fā)送MQ消息給財(cái)務(wù)中心。
2. 【財(cái)務(wù)中心】接收MQ消息 -> 校驗(yàn)客戶交易數(shù)據(jù) -> 調(diào)用資金平臺(tái)結(jié)算積分。
3. 【資金平臺(tái)】結(jié)算積分 -> 虛擬資產(chǎn)入賬。

其中，財(cái)務(wù)中心MQ消費(fèi)使用了一個(gè)基于Kafka二次封裝的組件，默認(rèn)通過(guò)應(yīng)用內(nèi)線程池異步消費(fèi)消息進(jìn)行業(yè)務(wù)處理（因?yàn)樾枰诙鄠€(gè)地方消費(fèi)），這個(gè)二開(kāi)的組件也已經(jīng)用了一年時(shí)間，相對(duì)較為穩(wěn)定。

OK，到這一步?jīng)]有發(fā)現(xiàn)什么問(wèn)題。

接下來(lái)，不出意外的話?cǎi)R上就會(huì)發(fā)生意外。

凌晨6點(diǎn)觸發(fā)P1級(jí)告警，由于應(yīng)用內(nèi)線程池被撐爆，應(yīng)用走拒絕策略737次，觸發(fā)SQL慢查詢持續(xù)10秒（剛好校驗(yàn)客戶交易數(shù)據(jù)操作用到了非索引列查數(shù)據(jù)庫(kù)）。

隨后進(jìn)行了問(wèn)題排查，分析完生產(chǎn)者、消費(fèi)者端的代碼，發(fā)現(xiàn)有以下問(wèn)題：

1. 消費(fèi)端財(cái)務(wù)中心對(duì)應(yīng)的消費(fèi)方法使用了默認(rèn)的異步方式處理消息，線程數(shù)大小用了默認(rèn)的200個(gè)線程，如果短時(shí)間內(nèi)接收多條MQ而又無(wú)法快速執(zhí)行完釋放線程，線程數(shù)達(dá)到200個(gè)必然會(huì)走拒絕策略報(bào)錯(cuò)，甚至影響其它異步執(zhí)行MQ的消費(fèi)者方法（共用了同一個(gè)線程池）。
2. 訂單中心同一時(shí)刻批量修改已過(guò)售后訂單，把發(fā)送MQ的方法包在了for循環(huán)中。這意味著如果同一時(shí)刻發(fā)送大量MQ消息，又因?yàn)榈谝粭l消費(fèi)者存在的隱患，將導(dǎo)致發(fā)送的MQ消息無(wú)法被正常消費(fèi)。

處理過(guò)程

分析完問(wèn)題，基本上能確定如何解決了，分三步：

第一步：對(duì)于線上消費(fèi)異常的數(shù)據(jù)，按照代碼邏輯重新跑SQL修復(fù)相應(yīng)數(shù)據(jù)。這件事需要第一時(shí)間做，不能因?yàn)槌绦虻膯?wèn)題影響客戶體驗(yàn)。

第二步：該MQ組件異步消費(fèi)的消息堆積能力受線程池大小影響，應(yīng)該把消息堆積的問(wèn)題交給專業(yè)的MQ自己負(fù)責(zé)，所以暫時(shí)關(guān)掉該Topic的異步執(zhí)行，不用線程池，改為同步。后續(xù)對(duì)該MQ組件進(jìn)行優(yōu)化，不再提供異步執(zhí)行方式，如使用類似@KafkaListener(topic = "xxx", groupId = "

appName.beanName.methodName")的方式，只不過(guò)需要?jiǎng)討B(tài)創(chuàng)建KafkaListener，利用MQ本身消費(fèi)者組的功能，避免消息堆積在應(yīng)用線程池內(nèi)。

第三步：通過(guò)業(yè)務(wù)規(guī)避，合理評(píng)估需求，對(duì)于已經(jīng)確定的場(chǎng)景，能合并的MQ請(qǐng)求、SQL請(qǐng)求、Feign接口調(diào)用請(qǐng)求，比如上面提到的for循環(huán)發(fā)送訂單已過(guò)售后通知、校驗(yàn)客戶交易數(shù)據(jù)、資金平臺(tái)積分入賬場(chǎng)景，把它們識(shí)別出來(lái)，通過(guò)批量合并請(qǐng)求的方式解決頻繁請(qǐng)求可能發(fā)生的問(wèn)題（以空間換頻率）。請(qǐng)求合并后還需要評(píng)估合并請(qǐng)求的大小限制，進(jìn)一步進(jìn)行請(qǐng)求切割，比如訂單合并后有10萬(wàn)條數(shù)據(jù)，放在一個(gè)請(qǐng)求里也不合理，應(yīng)該按照一定的訂單量切割后再發(fā)送請(qǐng)求。

這里分享一個(gè)領(lǐng)導(dǎo)（技術(shù)總監(jiān)）用了8年的需求分析方法：

總結(jié)一下

對(duì)于此類生產(chǎn)問(wèn)題，分三步解決：

• 第一，第一時(shí)間修復(fù)生產(chǎn)數(shù)據(jù)，避免影響客戶體驗(yàn)。
• 第二，找出臨時(shí)解決方案——找出問(wèn)題根因針對(duì)性解決。
• 第三，長(zhǎng)遠(yuǎn)的問(wèn)題規(guī)避方案——合理評(píng)估需求。