我們需要接受失望，因為它是有限的；我們不會失去希望，因為它是無窮的。
一、概述
隨著時間和業務的發展，資料庫中表的資料量會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個資料庫中的多張表中。
本篇文章是基於非事務訊息的非同步確保的方式來完成分庫分表中的事務問題。
二、需要解決問題
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 釋出！