為了驗(yàn)證我的猜想，command + 空格、鍵入idea并回車、打開對(duì)應(yīng)的工程、定位到對(duì)應(yīng)的方法處、迅速瀏覽一遍并思索片刻之后，真相大白！

服務(wù)B執(zhí)行完update語句之后，事務(wù)commit之前，還有兩個(gè)異步通知任務(wù)，使用的是spring的@Async注解，自定義的線程池，跟蹤日志中的線程標(biāo)志，排查過程中發(fā)現(xiàn)有的異步任務(wù)居然由原線程執(zhí)行！進(jìn)一步分析日志發(fā)現(xiàn)這種現(xiàn)象并不是一直發(fā)生，有時(shí)又是由異步線程執(zhí)行。開始排查線程池，線程池果然設(shè)置了callRunner的失敗策略。

所以，由原線程執(zhí)行時(shí)，事務(wù)的范圍如下：

定位到原因之后，修改線程池參數(shù)為常見策略，初始和最大線程數(shù)相同，隊(duì)列數(shù)9999，保證線程池的線程充足性。

修復(fù)

灰度

招呼測(cè)試妹紙測(cè)試

自信滿滿，悠閑喝水

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

三、梅開二度

“在高并發(fā)場(chǎng)景下，復(fù)現(xiàn)了這個(gè)問題，你快看一下”！測(cè)試妹紙對(duì)我投來鄙視的眼光犀利的說道：“修復(fù)好了，再喊我回歸哈，拜拜～”。

奇怪，為什么這么平常的一個(gè)update語句，怎么會(huì)執(zhí)行這么長(zhǎng)時(shí)間呢？難道出發(fā)了框架的bug導(dǎo)致事務(wù)提交延遲？不對(duì)不對(duì)，這個(gè)方向想偏了～也沒有其他地方在更新這個(gè)表了呀？不可能有表鎖，更不可能有行鎖呀……

masaga？！！

根據(jù)表鎖以及行鎖的思路，為了驗(yàn)證我的內(nèi)心OS猜想，立即使用 show processlist 進(jìn)行了連接查詢，果然有重大發(fā)現(xiàn)，除了服務(wù)B有連接之外，還有服務(wù)A的連接。而服務(wù)A又是服務(wù)B的上游系統(tǒng)！系統(tǒng)架構(gòu)如下：

執(zhí)行順序如下：

不被人信任的滋味很難受！為了重新贏回測(cè)試妹紙對(duì)我的信任，這次的bug修復(fù)只需成功不許失??！

四、解決方案

知道病根之后，問題就很簡(jiǎn)單了。

最理想的方案

對(duì)微服務(wù)架構(gòu)進(jìn)行重構(gòu)，但這樣做帶來的收益不高，現(xiàn)在手上還有優(yōu)先級(jí)更高的事情要做。

最實(shí)際的方案

是將服務(wù)A對(duì)服務(wù)B的調(diào)用和服務(wù)A的事務(wù)分離出來。這樣就不存在鎖競(jìng)爭(zhēng)的問題了。

五、總結(jié)

看到了這里，你心里是不是已經(jīng)在想：我靠，大廠的系統(tǒng)架構(gòu)真的很垃圾，我都是關(guān)著燈的～（走錯(cuò)片場(chǎng)～）

其實(shí)這個(gè)系統(tǒng)變成這樣是有歷史原因的，如果當(dāng)初的開發(fā)者能夠采用DDD的思想或者能夠明白微服務(wù)的對(duì)象高內(nèi)聚思想，或許今天就不會(huì)發(fā)生在我身上這場(chǎng)研發(fā)與測(cè)試之間的信任危機(jī)。

夕陽落下，夜晚籠罩著大地。路旁的小貓咪悠然站了起來，張大嘴巴打個(gè)哈欠的同時(shí)伸了個(gè)懶腰，然后走向3號(hào)門口，等待著心地善良的加班兒投食貓糧?！膀?yàn)證通過，早點(diǎn)下班”。不遠(yuǎn)處傳來測(cè)試妹紙的聲音，夾雜著中央空調(diào)吹出的風(fēng)聲。