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