我們需要接受失望，因為它是有限的；我們不會失去希望，因為它是無窮的。
一、概述
隨著時間和業(yè)務(wù)的發(fā)展，數(shù)據(jù)庫中表的數(shù)據(jù)量會越來越大，相應(yīng)地，數(shù)據(jù)操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個數(shù)據(jù)庫中的多張表中。
本篇文章是基于非事務(wù)消息的異步確保的方式來完成分庫分表中的事務(wù)問題。
二、需要解決問題
2.1 原有事務(wù)
由于分庫分表之后，新表在另外一個數(shù)據(jù)庫中，如何保證主庫和分庫的事務(wù)性是必須要解決的問題。
解決辦法：通過在主庫中創(chuàng)建一個流水表，把操作數(shù)據(jù)庫的邏輯映射為一條流水記錄。當(dāng)整個大事務(wù)執(zhí)行完畢后（流水被插入到流水表）,然后通過其他方式來執(zhí)行這段流水，保證最終一致性。
2.2 流水
所謂流水，可以理解為一條事務(wù)消息
上面通過在數(shù)據(jù)庫中創(chuàng)建一張流水表，使用一條流水記錄代表一個業(yè)務(wù)處理邏輯，因此，一個流水一定是能最終正確執(zhí)行的.因此，當(dāng)把一段業(yè)務(wù)代碼提取流水中必須要考慮到:
流水延遲處理性。流水不是實時處理的，而是用過流水執(zhí)行器來異步執(zhí)行的。因此，如果在原有邏輯中，需要特別注意后續(xù)流程對該流水是不是有實時依賴性（例如后續(xù)業(yè)務(wù)邏輯中會使用流水結(jié)果來做一些計算等）。
流水處理無序性。保證即使后生成的流水先執(zhí)行，也不能出現(xiàn)問題。
流水最終成功性。對每條插入的流水，該條流水一定要保證能執(zhí)行成功
因此，提取流水的時候:
流水處理越簡單越好
流失處理依賴越少越好
-
提取的流水在該業(yè)務(wù)邏輯中無實時性依賴
file
2.4 流水處理完成
因為流水表是放在原數(shù)據(jù)庫中，而流水處理完成后是操作分庫，如果分庫操作完成去更新老表流水消息，那么又是夸庫事務(wù)，如何保證流水狀態(tài)的更新和分庫也是在一個事務(wù)的？
解決辦法是：在分庫中創(chuàng)建一個流水表，當(dāng)流失處理完成以后，不是去更新老表狀態(tài)，而是插入分庫流水表中、
這樣做的好處：
一般會對流水做唯一索引，那么如果流水重復(fù)多次執(zhí)行的時候，插入分庫流水表的時候肯定由于唯一索引檢測不通過，整個事務(wù)就會回滾（當(dāng)然也可以在處理流水事前應(yīng)該再做一下冪等性判斷）
-
這樣通過判斷主庫流水是否在分庫中就能判斷一條流水是否執(zhí)行完畢
file
三、流水處理器基本框架
流水處理器其實不包含任何業(yè)務(wù)相關(guān)的處理邏輯，核心功能就是：
通知業(yè)務(wù)接入方何時處理什么樣的流水
檢驗流水執(zhí)行的成功
注：流水執(zhí)行器并不知道該流水表示什么邏輯，具體需要業(yè)務(wù)系統(tǒng)去識別后去執(zhí)行相對應(yīng)業(yè)務(wù)邏輯。
3.1 流水執(zhí)行任務(wù)
流水處理調(diào)度任務(wù)就是通過掃描待處理的流水，然后通知業(yè)務(wù)系統(tǒng)該執(zhí)行哪一條流水。
示意圖如下：
3.2 流水校驗任務(wù)
流水校驗任務(wù)就是要比較主庫和分庫中的流水記錄，對執(zhí)行未成功的流水通知業(yè)務(wù)系統(tǒng)進行重新處理，如果多次重試失敗則發(fā)出告警。
流程示意圖：
四、為什么不用事務(wù)消息
由于是既有項目（互聯(lián)網(wǎng)金融，所以是絕對不容忍有任何消息丟失或者消息處理失敗）進行改造，不使用事務(wù)消息有1個原因
需要額外引入消息隊列，增加系統(tǒng)的復(fù)雜度，而且也需要額外的邏輯保證和消息隊列通訊失敗的時候處理
其實1不算是主要原因，而是因為事務(wù)消息需要手動的commit和rollback（使用數(shù)據(jù)庫不需要），那么問題來了，spring中事務(wù)是有傳遞性的，那我們事務(wù)消息何時提交又是個大問題，例如 A.a()本來就是一個事務(wù)， 但是另外一個事務(wù)B.b()中又調(diào)用了A.a() 那事務(wù)消息提交是放在A.a()還是B.b()中呢？
本文由博客群發(fā)一文多發(fā)等運營工具平臺 OpenWrite 發(fā)布
