mysql分库分表面试_【53期】面试官:谈一下数据库分库分表之后,你是如何解决事务问题?...
點(diǎn)擊上方“Java面試題精選”,關(guān)注公眾號(hào)
面試刷圖,查缺補(bǔ)漏
>>號(hào)外:往期面試題,10篇為一個(gè)單位歸置到本公眾號(hào)菜單欄->面試題,有需要的歡迎翻閱。
一、概述
隨著時(shí)間和業(yè)務(wù)的發(fā)展,數(shù)據(jù)庫(kù)中表的數(shù)據(jù)量會(huì)越來(lái)越大,相應(yīng)地,數(shù)據(jù)操作,增刪改查的開(kāi)銷也會(huì)越來(lái)越大。因此,把其中一些大表進(jìn)行拆分到多個(gè)數(shù)據(jù)庫(kù)中的多張表中。
另一方面,在分庫(kù)分表以后還需要保證分庫(kù)分表的和主庫(kù)的事務(wù)一致性。這片文章介紹一下:https://zhuanlan.zhihu.com/p/25933039
本篇文章是基于非事務(wù)消息的異步確保的方式來(lái)完成分庫(kù)分表中的事務(wù)問(wèn)題。
二、需要解決問(wèn)題
2.1 原有事務(wù)
由于分庫(kù)分表之后,新表在另外一個(gè)數(shù)據(jù)庫(kù)中,如何保證主庫(kù)和分庫(kù)的事務(wù)性是必須要解決的問(wèn)題。
解決辦法:通過(guò)在主庫(kù)中創(chuàng)建一個(gè)流水表,把操作數(shù)據(jù)庫(kù)的邏輯映射為一條流水記錄。當(dāng)整個(gè)大事務(wù)執(zhí)行完畢后(流水被插入到流水表),然后通過(guò)其他方式來(lái)執(zhí)行這段流水,保證最終一致性。
2.2 流水
所謂流水,可以理解為一條事務(wù)消息
上面通過(guò)在數(shù)據(jù)庫(kù)中創(chuàng)建一張流水表,使用一條流水記錄代表一個(gè)業(yè)務(wù)處理邏輯,因此,一個(gè)流水一定是能最終正確執(zhí)行的.因此,當(dāng)把一段業(yè)務(wù)代碼提取流水中必須要考慮到:
流水延遲處理性。流水不是實(shí)時(shí)處理的,而是用過(guò)流水執(zhí)行器來(lái)異步執(zhí)行的。因此,如果在原有邏輯中,需要特別注意后續(xù)流程對(duì)該流水是不是有實(shí)時(shí)依賴性(例如后續(xù)業(yè)務(wù)邏輯中會(huì)使用流水結(jié)果來(lái)做一些計(jì)算等)。
流水處理無(wú)序性。保證即使后生成的流水先執(zhí)行,也不能出現(xiàn)問(wèn)題。
流水最終成功性。對(duì)每條插入的流水,該條流水一定要保證能執(zhí)行成功
因此,提取流水的時(shí)候:
流水處理越簡(jiǎn)單越好
流失處理依賴越少越好
提取的流水在該業(yè)務(wù)邏輯中無(wú)實(shí)時(shí)性依賴
2.3 流水處理器
流水處理器即要保證流水處理盡可能處理快,又能保證流水最終能執(zhí)行成功。
設(shè)想一個(gè)場(chǎng)景:當(dāng)出現(xiàn)某一條流水處理失敗,如果流失執(zhí)行器要等當(dāng)前流水執(zhí)行成功才繼續(xù)往后執(zhí)行,那么會(huì)影響后續(xù)流水的執(zhí)行,更嚴(yán)重的是一直卡在當(dāng)條記錄,導(dǎo)致整個(gè)系統(tǒng)出現(xiàn)問(wèn)題
因此,流水執(zhí)行器中設(shè)置2個(gè)任務(wù):
第一個(gè)任務(wù),流水處理任務(wù),已最快的速度執(zhí)行流水,如果流水處理失敗了,也不影響后面流水處理
第二個(gè)任務(wù),流水校驗(yàn)任務(wù),這個(gè)任務(wù)就是順序檢查流水記錄,保證所有流水都執(zhí)行成功,如果失敗,進(jìn)行重試,多次重試失敗以后發(fā)出告警以讓人工介入處理。
2.4 流水處理完成
因?yàn)榱魉硎欠旁谠瓟?shù)據(jù)庫(kù)中,而流水處理完成后是操作分庫(kù),如果分庫(kù)操作完成去更新老表流水消息,那么又是夸庫(kù)事務(wù),如何保證流水狀態(tài)的更新和分庫(kù)也是在一個(gè)事務(wù)的?
解決辦法是:在分庫(kù)中創(chuàng)建一個(gè)流水表,當(dāng)流失處理完成以后,不是去更新老表狀態(tài),而是插入分庫(kù)流水表中、
這樣做的好處:
一般會(huì)對(duì)流水做唯一索引,那么如果流水重復(fù)多次執(zhí)行的時(shí)候,插入分庫(kù)流水表的時(shí)候肯定由于唯一索引檢測(cè)不通過(guò),整個(gè)事務(wù)就會(huì)回滾(當(dāng)然也可以在處理流水事前應(yīng)該再做一下冪等性判斷)
這樣通過(guò)判斷主庫(kù)流水是否在分庫(kù)中就能判斷一條流水是否執(zhí)行完畢
三、流水處理器基本框架
流水處理器其實(shí)不包含任何業(yè)務(wù)相關(guān)的處理邏輯,核心功能就是:
通知業(yè)務(wù)接入方何時(shí)處理什么樣的流水
檢驗(yàn)流水執(zhí)行的成功
注:流水執(zhí)行器并不知道該流水表示什么邏輯,具體需要業(yè)務(wù)系統(tǒng)去識(shí)別后去執(zhí)行相對(duì)應(yīng)業(yè)務(wù)邏輯。
3.1 流水執(zhí)行任務(wù)
流水處理調(diào)度任務(wù)就是通過(guò)掃描待處理的流水,然后通知業(yè)務(wù)系統(tǒng)該執(zhí)行哪一條流水。
示意圖如下:
3.2 流水校驗(yàn)任務(wù)
流水校驗(yàn)任務(wù)就是要比較主庫(kù)和分庫(kù)中的流水記錄,對(duì)執(zhí)行未成功的流水通知業(yè)務(wù)系統(tǒng)進(jìn)行重新處理,如果多次重試失敗則發(fā)出告警。
流程示意圖:
四、為什么不用事務(wù)消息
由于是既有項(xiàng)目進(jìn)行改造(本人從事互聯(lián)網(wǎng)金融,所以是絕對(duì)不容忍有任何消息丟失或者消息處理失敗),不使用事務(wù)消息有1個(gè)原因
需要額外引入消息隊(duì)列,增加系統(tǒng)的復(fù)雜度,而且也需要額外的邏輯保證和消息隊(duì)列通訊失敗的時(shí)候處理
其實(shí)1不算是主要原因,而是因?yàn)槭聞?wù)消息需要手動(dòng)的commit和rollback(使用數(shù)據(jù)庫(kù)不需要),那么問(wèn)題來(lái)了,spring中事務(wù)是有傳遞性的,那我們事務(wù)消息何時(shí)提交又是個(gè)大問(wèn)題,例如 A.a()本來(lái)就是一個(gè)事務(wù), 但是另外一個(gè)事務(wù)B.b()中又調(diào)用了A.a() 那事務(wù)消息提交是放在A.a()還是B.b()中呢?
來(lái)源:www.cnblogs.com/lizo/p/8035036.html
最近五期
與其在網(wǎng)上拼命找題?不如馬上關(guān)注我們~
總結(jié)
以上是生活随笔為你收集整理的mysql分库分表面试_【53期】面试官:谈一下数据库分库分表之后,你是如何解决事务问题?...的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: linux php oci,Linux下
- 下一篇: 《零基础》MySQL UPDATE 更新