\“讀走從、判斷走主\“的一致性策略)
主從延遲會造成什么問題訂單系統(tǒng)讀走從、判斷走主的一致性策略承接上一篇《MySQL 讀寫分離完整鏈路》那篇講怎么把讀寫分離搭起來這篇只講搭建之后必然要還的那筆債——主從延遲。文中策略與判定全部來自筆者的微服務(wù)訂單系統(tǒng)order-system-cloud的落地實(shí)踐屬于備選方案、未落地的部分會顯式標(biāo)注。一、業(yè)務(wù)背景一個(gè)刪不掉的購物車先說一個(gè)真實(shí)場景它比任何原理圖都更能說明問題用戶點(diǎn)刪除購物車商品→ 請求打到主庫DELETE 成功接口返回200→ 用戶秒刷購物車列表這個(gè)查詢走了從庫 → 剛才刪掉的那一項(xiàng)又冒出來了用戶看到的現(xiàn)象是刪除失敗但數(shù)據(jù)庫里數(shù)據(jù)是對的、接口也返回成功了。如果沒有意識到主從延遲這個(gè) bug 會非常難查——因?yàn)槟阍谌魏我慌_庫上單獨(dú)查都是對的。同樣的形態(tài)還有很多用戶完成支付 → 主庫把訂單改成 PAID → 用戶秒進(jìn)訂單詳情走從庫→ 仍顯示待支付用戶下單成功 → 主庫寫入訂單 → 用戶秒進(jìn)我的訂單走從庫→ 列表里沒有這一單這三個(gè)場景有一個(gè)共同點(diǎn)“剛剛寫過的數(shù)據(jù)馬上就要讀”。這就是主從延遲唯一會咬人的地方也是本文全部策略的出發(fā)點(diǎn)。二、主從延遲的本質(zhì)異步復(fù)制主從復(fù)制靠三個(gè)線程接力主庫 Dump 線程 ──推 binlog──? 從庫 IO 線程 ──? relay log ──? 從庫 SQL 線程 逐條重放關(guān)鍵在于主庫提交事務(wù)時(shí)并不等待從庫重放完成。主庫只要把 binlog 寫出去就返回了從庫什么時(shí)候追平是它自己的事。這中間的時(shí)間差就是主從延遲replication lag。所以延遲不是一個(gè)故障而是異步復(fù)制的固有屬性。它不是會不會發(fā)生的問題而是這一瞬間有多長的問題——正常情況是毫秒級但只要有放大因素下一節(jié)會講它會突然拉長到秒級甚至分鐘級。這條認(rèn)知很重要如果你把延遲當(dāng)成故障來處理你會去修它但它是設(shè)計(jì)的一部分你只能在業(yè)務(wù)上決定哪些操作不能容忍它。下面是主從復(fù)制的完整鏈路與延遲產(chǎn)生的位置從庫主庫推送 binlog寫入逐條重放網(wǎng)絡(luò)傳輸主庫不等待從庫直接返回放大因素業(yè)務(wù)寫入事務(wù)提交Dump 線程binlogIO 線程relay logSQL 線程從庫數(shù)據(jù)延遲窗口 主庫提交到從庫重放完成的時(shí)間差毫秒級 → 秒級甚至分鐘級三、延遲會造成的四類線上問題把延遲的后果歸類比零散記場景更有用類型表現(xiàn)危險(xiǎn)程度讀己之寫失效用戶剛提交的修改自己刷新看不到高——用戶直接感知像 bug判斷依據(jù)過期先讀狀態(tài)再決定動作讀到舊狀態(tài)最高——會導(dǎo)致業(yè)務(wù)邏輯錯(cuò)誤不只是顯示問題冪等校驗(yàn)穿透靠查一下有沒有來防重查的是從庫高——可能重復(fù)扣減、重復(fù)下單監(jiān)控/統(tǒng)計(jì)延遲報(bào)表數(shù)字對不上、對賬有偏差中——可容忍但要知情其中第二類判斷依據(jù)過期是唯一會真正寫壞數(shù)據(jù)的也是本項(xiàng)目花最大力氣防的一類。舉個(gè)例子支付接口的validateOrder要先查訂單狀態(tài)確認(rèn)它是待支付才允許支付。如果這個(gè)查詢走了從庫而主從延遲剛好存在用戶重復(fù)點(diǎn)擊支付時(shí)——從庫可能還認(rèn)為訂單是WAIT_PAY于是第二次支付被放行。這不是顯示錯(cuò)誤是資損。四類問題的危險(xiǎn)程度可以這樣分層主從延遲四類線上問題讀己之寫失效判斷依據(jù)過期冪等校驗(yàn)穿透監(jiān)控/統(tǒng)計(jì)延遲用戶直接感知像 bug危險(xiǎn)程度高先讀狀態(tài)再決定動作讀到舊狀態(tài)危險(xiǎn)程度最高唯一會真正寫壞數(shù)據(jù)可能重復(fù)扣減、重復(fù)下單危險(xiǎn)程度高報(bào)表數(shù)字對不上、對賬有偏差危險(xiǎn)程度中可容忍但要知情四、項(xiàng)目的取舍讀走從、寫走主、判斷走主針對上面四類問題本項(xiàng)目的一致性策略壓縮成一句話讀走從、寫走主、判斷走主。落到DS注解上規(guī)則只有一條純讀、且容忍秒級延遲的方法才加DS(slave)寫方法、以及一切先讀后寫的方法一律不加注解默認(rèn)走 primary master。走從庫DS(slave)走主庫默認(rèn)不加注解OrderService.detail()—— 訂單詳情展示OrderService.create()/pay()/cancel()OrderService.myOrders()—— 我的訂單列表CartService.add()/updateQuantity()/remove()CartService.myCart()—— 購物車列表展示兩個(gè)定時(shí)調(diào)度器條件搶占 WAIT→SENDINGMessageService.myMessages()—— 消息列表MQ 消費(fèi)者插入 / 更新判斷規(guī)則可以寫成一句可執(zhí)行的檢查這個(gè)方法讀出來的數(shù)據(jù)會不會被用來做后續(xù)的判斷或?qū)懭霑妥咧鲙?。代碼形態(tài)ServicepublicclassOrderServiceImplimplementsOrderService{/** 純展示讀出來直接返回給前端不做任何判斷 → 容忍延遲走從庫 */DS(slave)OverridepublicOrderDetailVOdetail(LongorderId){...}/** 先讀后寫讀狀態(tài)是為了決定能不能改 → 必須走主庫 */OverrideTransactional(rollbackForException.class)publicvoidpay(LongorderId,LonguserId){OrderordervalidateOrder(orderId,userId);// ← 這一步讀到的狀態(tài)將決定后續(xù)寫入if(!OrderStatus.WAIT_PAY.name().equals(order.getStatus())){thrownewBizException(訂單狀態(tài)不允許支付);}// ... 更新為 PAID}}pay()不加DS(slave)不是忘了加而是刻意的它的讀是讀來改的一旦讀到延遲的舊數(shù)據(jù)邏輯就錯(cuò)了。萬一某個(gè)讀接口確實(shí)需要強(qiáng)一致怎么辦那就顯式聲明不要靠默認(rèn)值靠運(yùn)氣DS(master)// 顯式強(qiáng)制讀主庫我知道這里不能容忍延遲OverridepublicOrderVOgetForUpdate(LongorderId){...}關(guān)鍵原則是顯式容忍延遲走從庫是默認(rèn)選擇不容忍延遲走主庫必須寫出來。讓每一處我要強(qiáng)一致都在代碼里看得見。項(xiàng)目的核心決策邏輯可以用下面這張圖表達(dá)渲染錯(cuò)誤:Mermaid 渲染失敗: Parse error on line 4: ... D[加 DS(\slave\)走從庫] B -- -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR五、延遲從哪來五個(gè)放大因素正常情況延遲是毫秒級會讓它突然拉長的通常是這幾種從庫 SQL 線程單線程重放MySQL 5.6 之前從庫只有一個(gè) SQL 線程串行重放主庫并發(fā)寫入的壓力會全堆在這里大事務(wù)一次更新幾十萬行從庫要一行一行重放主庫早提交完了DDL 操作加字段、加索引在主庫執(zhí)行完從庫還要重放一遍從庫自身壓力大從庫既要重放 binlog 又要扛讀流量讀 QPS 一高重放就慢——這是讀寫分離方案里最諷刺的一種延遲來源binlog 格式的影響本項(xiàng)目用ROW格式記錄每行前后鏡像最安全代價(jià)是一次批量更新產(chǎn)生的 binlog 量遠(yuǎn)大于STATEMENT從庫要搬運(yùn)和重放的數(shù)據(jù)也更多。第 4 條值得單獨(dú)強(qiáng)調(diào)讀流量本身會加劇延遲而延遲又會讓人更想讀主庫主庫壓力上升——這是一個(gè)正反饋容量規(guī)劃時(shí)不能只看平均值。五個(gè)放大因素中最值得警惕的是第 4 條的正反饋循環(huán)從庫讀 QPS 升高從庫既要重放 binlog又要扛讀流量重放變慢延遲拉長用戶讀到舊數(shù)據(jù)更想讀主庫主庫壓力上升主庫寫入變慢六、三檔解法與項(xiàng)目的選擇業(yè)界應(yīng)對主從延遲有三檔手段從簡單到硬核檔位手段代價(jià)本項(xiàng)目第一檔寫后必須讀準(zhǔn)的強(qiáng)制讀主庫DS(master)幾乎沒有只是少了一個(gè)讀分流點(diǎn)?已落地第二檔半同步復(fù)制semi-sync主庫提交前等從庫確認(rèn)收到 binlog犧牲寫性能換強(qiáng)一致延遲敏感型寫入變慢? 未落地README 列為備選策略第三檔從庫并行復(fù)制MySQL 5.7 MTS從庫 SQL 線程并行重放需要配置且并行度受事務(wù)沖突限制? 未落地README 列為備選策略本項(xiàng)目的選擇是只用第一檔并且明確不承諾零延遲。理由是本項(xiàng)目的讀方法全部是列表展示類容忍秒級延遲凡是讀來改的都留在主庫了。也就是說——延遲仍然存在但它不再落在任何會寫壞數(shù)據(jù)的路徑上。這是一個(gè)很重要的表達(dá)方式不是我們消除了主從延遲而是我們把延遲隔離在了不會造成錯(cuò)誤的地方。三檔解法的取舍一目了然渲染錯(cuò)誤:Mermaid 渲染失敗: Parse error on line 3: ...加 DS(\master\)] A -- A1 -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR七、邊界與并發(fā)能承諾什么不能承諾什么寫這類方案時(shí)必須把邊界說清楚否則就是給自己埋雷能承諾的從庫上的查詢最終會與主庫一致異步復(fù)制保證最終一致任何讀后判斷/讀后修改的操作都在主庫上執(zhí)行不會因延遲產(chǎn)生錯(cuò)誤判斷本項(xiàng)目已按此規(guī)則劃分?jǐn)?shù)據(jù)源。不能承諾的從庫的讀不保證讀到最新數(shù)據(jù)——這是設(shè)計(jì)取舍不是缺陷極端情況下大事務(wù)、DDL、從庫過載延遲可能達(dá)到秒級以上展示類接口會出現(xiàn)短暫的數(shù)據(jù)偏舊DS(slave)的切換依賴 AOP 代理 ThreadLocal同類內(nèi)部this.xxx()自調(diào)用不走代理、Async/線程池場景 ThreadLocal 不跨線程傳遞——這兩種情況下注解會靜默失效退化為走默認(rèn)的 master不會報(bào)錯(cuò)。最后一條是并發(fā)邊界里最容易踩的注解失效的表現(xiàn)不是報(bào)錯(cuò)而是看起來正常但走了主庫。所以核查數(shù)據(jù)源路由時(shí)不能只看注解寫沒寫還要看調(diào)用路徑是否真的過了代理。八、面試與簡歷亮點(diǎn)能一句話說清策略“讀走從、寫走主、判斷走主”——把讀寫分離的一致性邊界講成了可執(zhí)行的規(guī)則而不是我們有讀寫分離知道延遲不是故障而是屬性因此方案的目標(biāo)是隔離而不是消滅這個(gè)認(rèn)知層次比背八股高能指出真正危險(xiǎn)的那類問題讀己之寫失效只是體驗(yàn)問題判斷依據(jù)過期才會寫壞數(shù)據(jù)——把風(fēng)險(xiǎn)按后果分級是工程判斷力的體現(xiàn)顯式優(yōu)先于默認(rèn)容忍延遲靠默認(rèn)、需要強(qiáng)一致必須顯式寫DS(master)讓例外在代碼里可見知道自己的注解會失效自調(diào)用、異步場景下DS靜默失效且不報(bào)錯(cuò)。九、場景題Q1用戶反饋刪了購物車商品又自己回來了但你查數(shù)據(jù)庫確認(rèn)數(shù)據(jù)是正確的。怎么解釋、怎么修解釋刪除走主庫、列表查詢走從庫用戶秒刷時(shí)從庫還沒重放到這次刪除于是讀到了刪除前的快照。數(shù)據(jù)是正確的用戶看到的是延遲窗口內(nèi)的舊快照。排查要點(diǎn)先確認(rèn)兩臺庫分別查這條記錄主庫已刪、從庫還在 → 立刻能定性為延遲而不是刪除失敗這一步能省掉大量無效排查。修法按性價(jià)比排序該場景強(qiáng)制讀主庫DS(master)或刪除成功后由接口直接返回刪除結(jié)果、前端本地移除該行不做二次查詢更通用的做法寫操作返回后對同一用戶短時(shí)間內(nèi)的讀請求強(qiáng)制走主庫寫后粘主庫窗口半同步復(fù)制 / 從庫并行復(fù)制按下延遲本身本項(xiàng)目未落地屬備選。關(guān)鍵提醒不要用加個(gè) sleep 等一下來解——那是把不確定性換成隨機(jī)性線上延遲一波動就會復(fù)發(fā)。Q2同事給pay()加上了DS(slave)想減輕主庫壓力說這個(gè)方法就是查一下訂單純讀。你怎么判斷這個(gè)改動能不能上判斷標(biāo)準(zhǔn)一句話這個(gè)讀的結(jié)果會不會被后面用來做判斷或?qū)懭雙ay()的validateOrder是典型的讀來改——它讀訂單狀態(tài)是為了決定能不能支付并且緊接著就要寫。走從庫意味著延遲窗口內(nèi)一筆已支付的訂單可能被從庫讀成WAIT_PAY于是重復(fù)支付被放行。這是資損不是體驗(yàn)問題。所以答案是不能上。正確做法是要減主庫壓力應(yīng)該從它周圍的純展示讀訂單詳情、我的訂單、購物車列表、消息列表入手而不是從帶判斷的讀入手。如果確實(shí)要優(yōu)化pay()方向是縮短它的主庫事務(wù)、減少鎖持有時(shí)間而不是把它的讀挪到從庫。一句話總結(jié)主從延遲是異步復(fù)制的固有屬性不可能被消滅只能被隔離。訂單系統(tǒng)的做法是把延遲全部趕到讀出來只用于展示的路徑上而把讀出來要用于判斷或修改的操作留在主庫——讀走從、寫走主、判斷走主。推薦標(biāo)簽MySQL、主從延遲、讀寫分離、數(shù)據(jù)一致性、微服務(wù) 主從延遲會造成什么問題？訂單系統(tǒng)\“讀走從、判斷走主\“的一致性策略
主從延遲會造成什么問題訂單系統(tǒng)讀走從、判斷走主的一致性策略承接上一篇《MySQL 讀寫分離完整鏈路》那篇講怎么把讀寫分離搭起來這篇只講搭建之后必然要還的那筆債——主從延遲。文中策略與判定全部來自筆者的微服務(wù)訂單系統(tǒng)order-system-cloud的落地實(shí)踐屬于備選方案、未落地的部分會顯式標(biāo)注。一、業(yè)務(wù)背景一個(gè)刪不掉的購物車先說一個(gè)真實(shí)場景它比任何原理圖都更能說明問題用戶點(diǎn)刪除購物車商品→ 請求打到主庫DELETE 成功接口返回200→ 用戶秒刷購物車列表這個(gè)查詢走了從庫 → 剛才刪掉的那一項(xiàng)又冒出來了用戶看到的現(xiàn)象是刪除失敗但數(shù)據(jù)庫里數(shù)據(jù)是對的、接口也返回成功了。如果沒有意識到主從延遲這個(gè) bug 會非常難查——因?yàn)槟阍谌魏我慌_庫上單獨(dú)查都是對的。同樣的形態(tài)還有很多用戶完成支付 → 主庫把訂單改成 PAID → 用戶秒進(jìn)訂單詳情走從庫→ 仍顯示待支付用戶下單成功 → 主庫寫入訂單 → 用戶秒進(jìn)我的訂單走從庫→ 列表里沒有這一單這三個(gè)場景有一個(gè)共同點(diǎn)“剛剛寫過的數(shù)據(jù)馬上就要讀”。這就是主從延遲唯一會咬人的地方也是本文全部策略的出發(fā)點(diǎn)。二、主從延遲的本質(zhì)異步復(fù)制主從復(fù)制靠三個(gè)線程接力主庫 Dump 線程 ──推 binlog──? 從庫 IO 線程 ──? relay log ──? 從庫 SQL 線程 逐條重放關(guān)鍵在于主庫提交事務(wù)時(shí)并不等待從庫重放完成。主庫只要把 binlog 寫出去就返回了從庫什么時(shí)候追平是它自己的事。這中間的時(shí)間差就是主從延遲replication lag。所以延遲不是一個(gè)故障而是異步復(fù)制的固有屬性。它不是會不會發(fā)生的問題而是這一瞬間有多長的問題——正常情況是毫秒級但只要有放大因素下一節(jié)會講它會突然拉長到秒級甚至分鐘級。這條認(rèn)知很重要如果你把延遲當(dāng)成故障來處理你會去修它但它是設(shè)計(jì)的一部分你只能在業(yè)務(wù)上決定哪些操作不能容忍它。下面是主從復(fù)制的完整鏈路與延遲產(chǎn)生的位置從庫主庫推送 binlog寫入逐條重放網(wǎng)絡(luò)傳輸主庫不等待從庫直接返回放大因素業(yè)務(wù)寫入事務(wù)提交Dump 線程binlogIO 線程relay logSQL 線程從庫數(shù)據(jù)延遲窗口 主庫提交到從庫重放完成的時(shí)間差毫秒級 → 秒級甚至分鐘級三、延遲會造成的四類線上問題把延遲的后果歸類比零散記場景更有用類型表現(xiàn)危險(xiǎn)程度讀己之寫失效用戶剛提交的修改自己刷新看不到高——用戶直接感知像 bug判斷依據(jù)過期先讀狀態(tài)再決定動作讀到舊狀態(tài)最高——會導(dǎo)致業(yè)務(wù)邏輯錯(cuò)誤不只是顯示問題冪等校驗(yàn)穿透靠查一下有沒有來防重查的是從庫高——可能重復(fù)扣減、重復(fù)下單監(jiān)控/統(tǒng)計(jì)延遲報(bào)表數(shù)字對不上、對賬有偏差中——可容忍但要知情其中第二類判斷依據(jù)過期是唯一會真正寫壞數(shù)據(jù)的也是本項(xiàng)目花最大力氣防的一類。舉個(gè)例子支付接口的validateOrder要先查訂單狀態(tài)確認(rèn)它是待支付才允許支付。如果這個(gè)查詢走了從庫而主從延遲剛好存在用戶重復(fù)點(diǎn)擊支付時(shí)——從庫可能還認(rèn)為訂單是WAIT_PAY于是第二次支付被放行。這不是顯示錯(cuò)誤是資損。四類問題的危險(xiǎn)程度可以這樣分層主從延遲四類線上問題讀己之寫失效判斷依據(jù)過期冪等校驗(yàn)穿透監(jiān)控/統(tǒng)計(jì)延遲用戶直接感知像 bug危險(xiǎn)程度高先讀狀態(tài)再決定動作讀到舊狀態(tài)危險(xiǎn)程度最高唯一會真正寫壞數(shù)據(jù)可能重復(fù)扣減、重復(fù)下單危險(xiǎn)程度高報(bào)表數(shù)字對不上、對賬有偏差危險(xiǎn)程度中可容忍但要知情四、項(xiàng)目的取舍讀走從、寫走主、判斷走主針對上面四類問題本項(xiàng)目的一致性策略壓縮成一句話讀走從、寫走主、判斷走主。落到DS注解上規(guī)則只有一條純讀、且容忍秒級延遲的方法才加DS(slave)寫方法、以及一切先讀后寫的方法一律不加注解默認(rèn)走 primary master。走從庫DS(slave)走主庫默認(rèn)不加注解OrderService.detail()—— 訂單詳情展示OrderService.create()/pay()/cancel()OrderService.myOrders()—— 我的訂單列表CartService.add()/updateQuantity()/remove()CartService.myCart()—— 購物車列表展示兩個(gè)定時(shí)調(diào)度器條件搶占 WAIT→SENDINGMessageService.myMessages()—— 消息列表MQ 消費(fèi)者插入 / 更新判斷規(guī)則可以寫成一句可執(zhí)行的檢查這個(gè)方法讀出來的數(shù)據(jù)會不會被用來做后續(xù)的判斷或?qū)懭霑妥咧鲙?。代碼形態(tài)ServicepublicclassOrderServiceImplimplementsOrderService{/** 純展示讀出來直接返回給前端不做任何判斷 → 容忍延遲走從庫 */DS(slave)OverridepublicOrderDetailVOdetail(LongorderId){...}/** 先讀后寫讀狀態(tài)是為了決定能不能改 → 必須走主庫 */OverrideTransactional(rollbackForException.class)publicvoidpay(LongorderId,LonguserId){OrderordervalidateOrder(orderId,userId);// ← 這一步讀到的狀態(tài)將決定后續(xù)寫入if(!OrderStatus.WAIT_PAY.name().equals(order.getStatus())){thrownewBizException(訂單狀態(tài)不允許支付);}// ... 更新為 PAID}}pay()不加DS(slave)不是忘了加而是刻意的它的讀是讀來改的一旦讀到延遲的舊數(shù)據(jù)邏輯就錯(cuò)了。萬一某個(gè)讀接口確實(shí)需要強(qiáng)一致怎么辦那就顯式聲明不要靠默認(rèn)值靠運(yùn)氣DS(master)// 顯式強(qiáng)制讀主庫我知道這里不能容忍延遲OverridepublicOrderVOgetForUpdate(LongorderId){...}關(guān)鍵原則是顯式容忍延遲走從庫是默認(rèn)選擇不容忍延遲走主庫必須寫出來。讓每一處我要強(qiáng)一致都在代碼里看得見。項(xiàng)目的核心決策邏輯可以用下面這張圖表達(dá)渲染錯(cuò)誤:Mermaid 渲染失敗: Parse error on line 4: ... D[加 DS(\slave\)走從庫] B -- -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR五、延遲從哪來五個(gè)放大因素正常情況延遲是毫秒級會讓它突然拉長的通常是這幾種從庫 SQL 線程單線程重放MySQL 5.6 之前從庫只有一個(gè) SQL 線程串行重放主庫并發(fā)寫入的壓力會全堆在這里大事務(wù)一次更新幾十萬行從庫要一行一行重放主庫早提交完了DDL 操作加字段、加索引在主庫執(zhí)行完從庫還要重放一遍從庫自身壓力大從庫既要重放 binlog 又要扛讀流量讀 QPS 一高重放就慢——這是讀寫分離方案里最諷刺的一種延遲來源binlog 格式的影響本項(xiàng)目用ROW格式記錄每行前后鏡像最安全代價(jià)是一次批量更新產(chǎn)生的 binlog 量遠(yuǎn)大于STATEMENT從庫要搬運(yùn)和重放的數(shù)據(jù)也更多。第 4 條值得單獨(dú)強(qiáng)調(diào)讀流量本身會加劇延遲而延遲又會讓人更想讀主庫主庫壓力上升——這是一個(gè)正反饋容量規(guī)劃時(shí)不能只看平均值。五個(gè)放大因素中最值得警惕的是第 4 條的正反饋循環(huán)從庫讀 QPS 升高從庫既要重放 binlog又要扛讀流量重放變慢延遲拉長用戶讀到舊數(shù)據(jù)更想讀主庫主庫壓力上升主庫寫入變慢六、三檔解法與項(xiàng)目的選擇業(yè)界應(yīng)對主從延遲有三檔手段從簡單到硬核檔位手段代價(jià)本項(xiàng)目第一檔寫后必須讀準(zhǔn)的強(qiáng)制讀主庫DS(master)幾乎沒有只是少了一個(gè)讀分流點(diǎn)?已落地第二檔半同步復(fù)制semi-sync主庫提交前等從庫確認(rèn)收到 binlog犧牲寫性能換強(qiáng)一致延遲敏感型寫入變慢? 未落地README 列為備選策略第三檔從庫并行復(fù)制MySQL 5.7 MTS從庫 SQL 線程并行重放需要配置且并行度受事務(wù)沖突限制? 未落地README 列為備選策略本項(xiàng)目的選擇是只用第一檔并且明確不承諾零延遲。理由是本項(xiàng)目的讀方法全部是列表展示類容忍秒級延遲凡是讀來改的都留在主庫了。也就是說——延遲仍然存在但它不再落在任何會寫壞數(shù)據(jù)的路徑上。這是一個(gè)很重要的表達(dá)方式不是我們消除了主從延遲而是我們把延遲隔離在了不會造成錯(cuò)誤的地方。三檔解法的取舍一目了然渲染錯(cuò)誤:Mermaid 渲染失敗: Parse error on line 3: ...加 DS(\master\)] A -- A1 -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR七、邊界與并發(fā)能承諾什么不能承諾什么寫這類方案時(shí)必須把邊界說清楚否則就是給自己埋雷能承諾的從庫上的查詢最終會與主庫一致異步復(fù)制保證最終一致任何讀后判斷/讀后修改的操作都在主庫上執(zhí)行不會因延遲產(chǎn)生錯(cuò)誤判斷本項(xiàng)目已按此規(guī)則劃分?jǐn)?shù)據(jù)源。不能承諾的從庫的讀不保證讀到最新數(shù)據(jù)——這是設(shè)計(jì)取舍不是缺陷極端情況下大事務(wù)、DDL、從庫過載延遲可能達(dá)到秒級以上展示類接口會出現(xiàn)短暫的數(shù)據(jù)偏舊DS(slave)的切換依賴 AOP 代理 ThreadLocal同類內(nèi)部this.xxx()自調(diào)用不走代理、Async/線程池場景 ThreadLocal 不跨線程傳遞——這兩種情況下注解會靜默失效退化為走默認(rèn)的 master不會報(bào)錯(cuò)。最后一條是并發(fā)邊界里最容易踩的注解失效的表現(xiàn)不是報(bào)錯(cuò)而是看起來正常但走了主庫。所以核查數(shù)據(jù)源路由時(shí)不能只看注解寫沒寫還要看調(diào)用路徑是否真的過了代理。八、面試與簡歷亮點(diǎn)能一句話說清策略“讀走從、寫走主、判斷走主”——把讀寫分離的一致性邊界講成了可執(zhí)行的規(guī)則而不是我們有讀寫分離知道延遲不是故障而是屬性因此方案的目標(biāo)是隔離而不是消滅這個(gè)認(rèn)知層次比背八股高能指出真正危險(xiǎn)的那類問題讀己之寫失效只是體驗(yàn)問題判斷依據(jù)過期才會寫壞數(shù)據(jù)——把風(fēng)險(xiǎn)按后果分級是工程判斷力的體現(xiàn)顯式優(yōu)先于默認(rèn)容忍延遲靠默認(rèn)、需要強(qiáng)一致必須顯式寫DS(master)讓例外在代碼里可見知道自己的注解會失效自調(diào)用、異步場景下DS靜默失效且不報(bào)錯(cuò)。九、場景題Q1用戶反饋刪了購物車商品又自己回來了但你查數(shù)據(jù)庫確認(rèn)數(shù)據(jù)是正確的。怎么解釋、怎么修解釋刪除走主庫、列表查詢走從庫用戶秒刷時(shí)從庫還沒重放到這次刪除于是讀到了刪除前的快照。數(shù)據(jù)是正確的用戶看到的是延遲窗口內(nèi)的舊快照。排查要點(diǎn)先確認(rèn)兩臺庫分別查這條記錄主庫已刪、從庫還在 → 立刻能定性為延遲而不是刪除失敗這一步能省掉大量無效排查。修法按性價(jià)比排序該場景強(qiáng)制讀主庫DS(master)或刪除成功后由接口直接返回刪除結(jié)果、前端本地移除該行不做二次查詢更通用的做法寫操作返回后對同一用戶短時(shí)間內(nèi)的讀請求強(qiáng)制走主庫寫后粘主庫窗口半同步復(fù)制 / 從庫并行復(fù)制按下延遲本身本項(xiàng)目未落地屬備選。關(guān)鍵提醒不要用加個(gè) sleep 等一下來解——那是把不確定性換成隨機(jī)性線上延遲一波動就會復(fù)發(fā)。Q2同事給pay()加上了DS(slave)想減輕主庫壓力說這個(gè)方法就是查一下訂單純讀。你怎么判斷這個(gè)改動能不能上判斷標(biāo)準(zhǔn)一句話這個(gè)讀的結(jié)果會不會被后面用來做判斷或?qū)懭雙ay()的validateOrder是典型的讀來改——它讀訂單狀態(tài)是為了決定能不能支付并且緊接著就要寫。走從庫意味著延遲窗口內(nèi)一筆已支付的訂單可能被從庫讀成WAIT_PAY于是重復(fù)支付被放行。這是資損不是體驗(yàn)問題。所以答案是不能上。正確做法是要減主庫壓力應(yīng)該從它周圍的純展示讀訂單詳情、我的訂單、購物車列表、消息列表入手而不是從帶判斷的讀入手。如果確實(shí)要優(yōu)化pay()方向是縮短它的主庫事務(wù)、減少鎖持有時(shí)間而不是把它的讀挪到從庫。一句話總結(jié)主從延遲是異步復(fù)制的固有屬性不可能被消滅只能被隔離。訂單系統(tǒng)的做法是把延遲全部趕到讀出來只用于展示的路徑上而把讀出來要用于判斷或修改的操作留在主庫——讀走從、寫走主、判斷走主。推薦標(biāo)簽MySQL、主從延遲、讀寫分離、數(shù)據(jù)一致性、微服務(wù)