隨著時間和業務的發展，資料庫中表的資料量會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個資料庫中的多張表中。
另一方面，在分庫分表以後還需要保證分庫分表的和主庫的事務一致性。這片文章介紹一下：
本篇文章是基於非事務訊息的非同步確保的方式來完成分庫分表中的事務問題。
由於分庫分表之後，新錶在另外乙個資料庫中，如何保證主庫和分庫的事務性是必須要解決的問題。
解決辦法：通過在主庫中建立乙個流水表，把運算元據庫的邏輯對映為一條流水記錄。當整個大事務執行完畢後（流水被插入到流水表）,然後通過其他方式來執行這段流水，保證最終一致性。
所謂流水，可以理解為一條事務訊息
上面通過在資料庫中建立一張流水表，使用一條流水記錄代表乙個業務處理邏輯，因此，乙個流水一定是能最終正確執行的.因此，當把一段業務**提取流水中必須要考慮到:
流水延遲處理性。流水不是實時處理的，而是用過流水執行器來非同步執行的。因此，如果在原有邏輯中，需要特別注意後續流程對該流水是不是有實時依賴性（例如後續業務邏輯中會使用流水結果來做一些計算等）。
流水處理無序性。保證即使後生成的流水先執行，也不能出現問題。
流水最終成功性。對每條插入的流水，該條流水一定要保證能執行成功
因此，提取流水的時候:
流水處理越簡單越好
流失處理依賴越少越好
提取的流水在該業務邏輯中無實時性依賴
流水處理器即要保證流水處理盡可能處理快，又能保證流水最終能執行成功。
設想乙個場景：當出現某一條流水處理失敗，如果流失執行器要等當前流水執行成功才繼續往後執行，那麼會影響後續流水的執行，更嚴重的是一直卡在當條記錄，導致整個系統出現問題
因此，流水執行器中設定2個任務：
第乙個任務,流水處理任務，已最快的速度執行流水，如果流水處理失敗了，也不影響後面流水處理
第二個任務,流水校驗任務，這個任務就是順序檢查流水記錄，保證所有流水都執行成功，如果失敗，進行重試，多次重試失敗以後發出告警以讓人工介入處理。
因為流水表是放在原資料庫中，而流水處理完成後是操作分庫，如果分庫操作完成去更新老表流水訊息，那麼又是誇庫事務，如何保證流水狀態的更新和分庫也是在乙個事務的？
解決辦法是：在分庫中建立乙個流水表，當流失處理完成以後，不是去更新老表狀態，而是插入分庫流水表中、
這樣做的好處：
一般會對流水做唯一索引，那麼如果流水重複多次執行的時候，插入分庫流水表的時候肯定由於唯一索引檢測不通過，整個事務就會回滾（當然也可以在處理流水事前應該再做一下冪等性判斷）
這樣通過判斷主庫流水是否在分庫中就能判斷一條流水是否執行完畢
通知業務接入方何時處理什麼樣的流水
檢驗流水執行的成功
注：流水執行器並不知道該流水表示什麼邏輯，具體需要業務系統去識別後去執行相對應業務邏輯。
流水處理排程任務就是通過掃瞄待處理的流水，然後通知業務系統該執行哪一條流水。
示意圖如下：
流水校驗任務就是要比較主庫和分庫中的流水記錄，對執行未成功的流水通知業務系統進行重新處理，如果多次重試失敗則發出告警。
流程示意圖：
由於是既有專案進行改造（本人從事網際網路金融，所以是絕對不容忍有任何訊息丟失或者訊息處理失敗)，不使用事務訊息有1個原因
需要額外引入訊息佇列，增加系統的複雜度，而且也需要額外的邏輯保證和訊息佇列通訊失敗的時候處理
其實1不算是主要原因，而是因為事務訊息需要手動的commit和rollback（使用資料庫不需要），那麼問題來了，spring中事務是有傳遞性的，那我們事務訊息何時提交又是個大問題，例如 a.a()本來就是乙個事務， 但是另外乙個事務b.b()中又呼叫了a.a() 那事務訊息提交是放在a.a()還是b.b()中呢？
分庫分表的解決方案
思路 1 完整閱讀分庫 分表策略，注意區分分庫與分表的不同，撰寫閱讀筆記。2 試驗基於ibatis spring2.0的分庫原始碼，注意思考路由的規則。3 試驗分表的原始碼實現，一般採用ibatis2.0以後的動態表名實現。以長春市教育公共服務平台管理軟體為例，在master庫中設定一張表，記錄每個...
分庫分表落地解決方案
隨著系統不斷的執行，當資料庫的資料開始超過千萬 上億時，mysql資料庫將承受更大的壓力。資料是企業生存的根本，資料庫的健康狀況將直接決了定企業的競爭力。為了更好的緩解資料庫壓力，使得系統更高效的執行，落地的解決方案有 1 分庫 也叫垂直拆分，即 每個模組對應乙個單獨的資料庫 2 分表 也叫水平拆分...
關係型資料庫分庫分表解決方案
關係型資料庫單庫或單錶在資料達到一定量級後，單個節點的就會出現效能瓶頸。通常的做法就是考慮分庫分表。分庫降低了單點機器的負載 分表，提高了資料操作的效率，尤其是write操作的效率。1 user id為區分，1 1000的對應db1，1001 2000的對應db2，以此類推 優點 可部分遷移 缺點 ...