本篇嘗試懸疑推理風(fēng)劇本殺，劇情純屬虛構(gòu)（若有雷同實(shí)屬巧合)：應(yīng)用 A 更新了 MySQL 數(shù)據(jù) -> canal 監(jiān)聽 binlog ，發(fā)給 MQ -> 應(yīng)用 B 消費(fèi) MQ，并向 A 發(fā)起 Dubbo 請(qǐng)求 -> 應(yīng)用 A 處理時(shí)卻查到了更新前的數(shù)據(jù)。這個(gè)情況多數(shù)人都沒遇到過，但提前了解并規(guī)避是必要的。

本劇本殺分上下兩章：

首章：《??若不是SkyWalking，MySQL的這個(gè)鍋都沒人背了-首章??》?

終章：《??若不是SkyWalking，MySQL的這個(gè)鍋都沒人背了-終章??》（本篇）

請(qǐng)按需回顧前情，方便你盡快融入角色（戲精上身）。

一、前情回顧

在首章劇情中你在技術(shù)部門負(fù)責(zé)鏈路追蹤系統(tǒng)和數(shù)據(jù)庫中間件等，在一次日常技術(shù)支持中，遇到了神奇的現(xiàn)象：

應(yīng)用 A 將 MySQL 中 x 訂單記錄里的 y 字段從 ccc 變成了 ddd

canal 監(jiān)聽 DB 中的訂單表，從 binlog 中感知到 x 記錄變更信息后，發(fā)到 MQ

應(yīng)用 B 消費(fèi)這個(gè) MQ，收到這條消息后，處理流程中會(huì)再調(diào)用應(yīng)用 A 的 Dubbo 服務(wù)，查詢一些信息

應(yīng)用 A 響應(yīng) Dubbo 請(qǐng)求時(shí)，處理邏輯中還會(huì)從 MySQL 中查詢這條 x 訂單記錄，但是?。?！讀出的狀態(tài)字段居然還是老數(shù)據(jù) ccc

DB 是 MySQL ，采用讀寫分離架構(gòu)，主從采用異步同步

你梳理的數(shù)據(jù)流轉(zhuǎn)圖如下：

數(shù)據(jù)流轉(zhuǎn)圖

通過這個(gè)數(shù)據(jù)流轉(zhuǎn)圖可以看出讀數(shù)據(jù)有如下 3 種途徑：

• 6.1 讀緩存
• 6.2 讀 slave-DB
• 6.3 讀 master-DB

你反復(fù)思索之后推測(cè) 6.1 或 6.2 這兩種途徑很可能會(huì)讀取到舊值，但經(jīng)梳理排查將各方信息整合后，似乎并沒有執(zhí)行 6.1 的讀緩存，也沒有執(zhí)行 6.2 的讀 slave-DB，你也認(rèn)定不會(huì)是數(shù)據(jù)庫中間件的路由機(jī)制有漏洞，而 DBA 也不認(rèn)為 master-DB 有問題，應(yīng)用 A 也不認(rèn)為他指定讀 master-DB 的代碼有問題，老王也不認(rèn)為他的 canal 讀到的 binlog 有問題。但由于沒有 trace 信息提供直接有效的證據(jù)，各方只能保留意見，不亂猜疑。

面面相覷好久，大家心照不宣地望向了導(dǎo)演，作為主角的你去問導(dǎo)演接下來怎么演。

導(dǎo)演也著急，把編劇叫來朝他怒吼：“那誰，這都演完了，你劇本還沒寫出來嘛？”

只見編劇不慌不忙的把劇本遞給導(dǎo)演，導(dǎo)演定睛一看，劇本上寫著"沒有有效的觀測(cè)數(shù)據(jù)，又沒有辦法復(fù)現(xiàn)，可能只有上帝視角知道是哪個(gè)環(huán)節(jié)有問題，要不問問上帝？”。

此時(shí)有人自稱上帝的站出來說：”應(yīng)用 A、應(yīng)用 B、canal 都接入 SkyWalking，等下次復(fù)現(xiàn)時(shí)，根據(jù)鏈路信息來尋找線索“。

二、終章劇本

因劇情所需，這次你在技術(shù)部門負(fù)責(zé) canal 和 MQ 等，情節(jié)延續(xù)上一次的排障經(jīng)歷...

突然，導(dǎo)演大喊：男主請(qǐng)就位... 預(yù)備 ! Action!

你：我去，咋的這就又開始演了？

三、心中的疑慮

當(dāng)聽完上帝讓接 SkyWalking 后，你必須開始心中有疑慮，疑慮些什么呢？終章劇本要求作為主角的你，要好好想一想為什么接入 SkyWalking 后就能準(zhǔn)確定位問題，幫助定位問題的信息 SkyWalking 是提供的？因?yàn)椴簧瞄L(zhǎng)這個(gè)領(lǐng)域，你很頭疼；倘若剛好你很熟悉 SkyWalking ，這里也需要假裝不熟悉且頭疼一下，導(dǎo)演要求就這么演。。。

頭疼了一會(huì)兒，你突然想到隔壁老張，在首章中是主角，負(fù)責(zé) SkyWalking ，于是你去咨詢 SkyWalking 能提供哪些有效的信息，老張拿出之前梳理的圖，指著其中幾個(gè)關(guān)鍵環(huán)節(jié)：

• 應(yīng)用 A 什么時(shí)候開始更新記錄，什么時(shí)候結(jié)束更新記錄
• 應(yīng)用 B 什么時(shí)候消費(fèi) MQ，什么時(shí)候請(qǐng)求應(yīng)用 A，應(yīng)用 A 什么時(shí)候開始執(zhí)行的查詢，查詢的是哪里？用緩存沒？如果沒用緩存，訪問的又是哪個(gè) DB？

這些關(guān)鍵信息 SkyWalking 的 trace 中都有記錄，且在界面中清晰可見，

老張繼續(xù)解釋說，雖然當(dāng)前的 MySQL 沒有傳遞 traceId 信息，會(huì)導(dǎo)致鏈路斷開成更新和查詢這兩條 trace，但是可以通過關(guān)鍵字從日志中檢索出這兩條 trace 的 traceId(下文用 TID) 。

聽完老張的講解，你了解并相信了 SkyWalking 的能力。原本你也推測(cè)查詢的是 slave-DB 或緩存，所以當(dāng)時(shí)下意識(shí)的決策就是等到復(fù)現(xiàn)后用 trace 信息來印證你的推測(cè)；不過老張?jiān)谙掳鄷r(shí)又向你拋出一個(gè)疑慮：會(huì)不會(huì)真有當(dāng) canal 讀到 binlog 時(shí) MySQL 事務(wù)還未完成提交的可能呢？

從你以往的經(jīng)驗(yàn)看是沒有這個(gè)情況的，但被老張這么一問卻不自信了。難道當(dāng)前版本的 canal 同步 binlog 的機(jī)制有問題？“到底有沒有問題呢，到底有沒有呢？”這個(gè)聲音一直在你耳邊縈繞，莫名感讓你覺得很不踏實(shí)，于是之后便在空閑時(shí)搜集學(xué)習(xí) MySQL 同步機(jī)制的更多內(nèi)幕。

四、問題再現(xiàn)

大約兩周后，問題排查群突然出現(xiàn)@全員的消息，想到可能是問題再現(xiàn)，你趕緊點(diǎn)開查看；只見在群聊窗口中已經(jīng)發(fā)出了把 x 記錄的 y 字段從 ccc 更新成 ddd 這個(gè)過程的 TID 以及 trace 信息截圖

非原截圖

因?yàn)閯∏樗?，作為本章主角的你，此時(shí)已很熟悉 SkyWalking 了，當(dāng)看到這個(gè)截圖后，親自在 SkyWalking 的 web 頁中通過此 TID 查看 trace 信息，點(diǎn)擊Mysql/JDBI/Connection/commit，看到 commit 的具體信息如下：

五、鐵證如山

你從 trace 信息中篩選出應(yīng)用 A 將 x 訂單記錄里 y 字段從 ccc 變成了 ddd操作的關(guān)鍵信息是：

• 事務(wù)發(fā)生在 MySQL 實(shí)例 serviceA-xxxx 中（這是 master-DB）
• 事務(wù) commit 的開始是 09:58:54 的 第 72 毫秒（后邊都只顯示毫秒)
• 事務(wù) commit 的結(jié)束是在第 123 毫秒

之后又快速從 SkyWalking 的 web 頁中查看核實(shí)應(yīng)用 A 查詢數(shù)據(jù)的 trace 信息，沒有讀 Mybatis 緩存、沒有讀 slave-DB，真兒真兒的是從 master-DB 中查詢數(shù)據(jù)。至此， trace 信息提供的信息有效證明了 應(yīng)用 A 更新記錄和查詢記錄都發(fā)生在 master-DB serviceA-xxxx 中。

劇本提醒，擁有主角光環(huán)的你，此時(shí)已淡定、嫻熟的把兩條 trace 信息中關(guān)鍵事項(xiàng)的時(shí)間節(jié)點(diǎn) 結(jié)合 mysql 和 canal 日志（canal 系統(tǒng)還未接 SkyWalking，只能看日志信息）整理了出來，情況如下：

• 第 72 毫秒：應(yīng)用 A 更新事務(wù) commit 開始
• 第 73 毫秒：MySQL 服務(wù)端開始寫 Binlog
• 第 77 毫秒：canal 同步到 Binlog 后發(fā)送到 MQ
• 第 78 毫秒：應(yīng)用 B 拉取到 canal 消息后，向應(yīng)用 A 發(fā)起 Dubbo 調(diào)用
• 第 88 毫秒：應(yīng)用 A 查詢 Mysql
• 第 123 毫秒：應(yīng)用 A 的事務(wù) commit 結(jié)束返回

劇本提醒：作為主角的你，絕對(duì)不能表現(xiàn)出驚訝，但其他群演看完你整理的信息后，必需配合表演出下圖中的表情（導(dǎo)演強(qiáng)調(diào)，怎么夸張?jiān)趺囱荩?/p>

六、揭開玄機(jī)

因兩周前隔壁老張?zhí)岢鲆蓱]后，你就已經(jīng)開始查閱資料學(xué)習(xí) MySQL 8（今年是從 5.6 升級(jí)了）的同步機(jī)制，大腦知識(shí)庫中的資料顯示 MySQL 是分兩階段處理事物請(qǐng)求的，其中跟劇情密切相關(guān)的是第二階段的 3 個(gè)核心步驟：

• 寫 binlog

當(dāng)寫完 biblog 后，事務(wù)已經(jīng)提交并持久化了，若發(fā)生崩潰，重啟之后就能正確恢復(fù)

• 同步 binlog

各種同步機(jī)制有差異

• 寫 engine

會(huì)處理釋放鎖，釋放 mvcc 相關(guān)的 read view 等；注意只有寫完 engine 之后，事務(wù)中的變更才能被查詢到

• 客戶端 commit 請(qǐng)求返回

綜合上述的信息，你將整個(gè)流程整理成下圖:

讀寫流程時(shí)序

并在圖中指出，這兩次異常的情況的發(fā)生，全是因?yàn)樵谧x x 記錄的時(shí)候，master-DB 中寫 engine 尚未完成，你之所以在上圖中使用2.謎之操作的名稱，是因?yàn)?MySQL 并不確定這個(gè)同步耗時(shí)是多長(zhǎng)；而且在強(qiáng)同步、半同步的機(jī)制下實(shí)現(xiàn)邏輯更復(fù)雜，可能出現(xiàn)此問題的概率會(huì)比異步同步模式更高，因細(xì)節(jié)和劇情的關(guān)系不那么密切，本劇本里并沒有過多的描述，只提供了下邊這個(gè)更為細(xì)致的流程圖：

來自網(wǎng)絡(luò)

通過你給出的解釋和資料，除了老張的表情看起來是還在糾結(jié)著什么，其他眾人皆表示此瓜香甜可口、回味無窮，經(jīng)過學(xué)習(xí)思考后對(duì)此情況基本達(dá)成共識(shí)，開始考慮如何應(yīng)對(duì)這個(gè)小概率事件。

七、新的疑慮和答案

第二天下班后，老張又找到你探討為什么應(yīng)用 A 的服務(wù)邏輯并未變更，而是升級(jí) 8.x 之后這個(gè)問題才開始出現(xiàn)（雖然概率不高）；據(jù)老張講，昨夜他查閱了好多資料，其中有一個(gè)關(guān)鍵信息是寫 engine 后更新才能被查到，但是 5.7 開始，寫 engine 的時(shí)機(jī)被調(diào)整了：

5.6 版本中是先寫 engine 再同步，由于寫 engine 的時(shí)機(jī)較早，產(chǎn)生問題的概率就更低。

5.7 提供的默認(rèn)邏輯是先同步，再寫 engine，由于同步前置了就可能帶來更多的具有不確定性的耗時(shí)

MySQL 5.7 默認(rèn)同步機(jī)制的變化

八、建議

總結(jié)來看，無論是 5.6 還是 5.7 + ，從邏輯看只是概率不同，監(jiān)聽 binlog 的方案始終是無法避免這類問題的。因無法確認(rèn) MySQL 的最大延遲時(shí)間，你的 canal 也無法使用 MQ 定時(shí)延遲消息的機(jī)制，因?yàn)檠舆t時(shí)間設(shè)大設(shè)小都不合適，你給出可行的 2 個(gè)建議：

異常重試 ：異常時(shí)借助 MQ 的 delay 重試機(jī)制多試幾次。

采用新的實(shí)現(xiàn)架構(gòu)：從根本上規(guī)避再去查詢 DB。

本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)染色」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系聯(lián)系【架構(gòu)染色】公眾號(hào)作者。