數據庫分庫分表之后該如何解決事務問題

今天就跟大家聊聊有關數據庫分庫分表之后該如何解決事務問題，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

一、概述

隨著時間和業務的發展，數據庫中表的數據量會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個數據庫中的多張表中。

本篇文章是基于非事務消息的異步確保的方式來完成分庫分表中的事務問題。

二、需要解決問題

2.1 原有事務

由于分庫分表之后，新表在另外一個數據庫中，如何保證主庫和分庫的事務性是必須要解決的問題。

解決辦法：通過在主庫中創建一個流水表，把操作數據庫的邏輯映射為一條流水記錄。當整個大事務執行完畢后（流水被插入到流水表）,然后通過其他方式來執行這段流水，保證最終一致性。

2.2 流水

所謂流水，可以理解為一條事務消息

上面通過在數據庫中創建一張流水表，使用一條流水記錄代表一個業務處理邏輯，因此，一個流水一定是能最終正確執行的.因此，當把一段業務代碼提取流水中必須要考慮到:

流水延遲處理性。流水不是實時處理的，而是用過流水執行器來異步執行的。因此，如果在原有邏輯中，需要特別注意后續流程對該流水是不是有實時依賴性（例如后續業務邏輯中會使用流水結果來做一些計算等）。

流水處理無序性。保證即使后生成的流水先執行，也不能出現問題。

流水最終成功性。對每條插入的流水，該條流水一定要保證能執行成功

因此，提取流水的時候:

流水處理越簡單越好

流失處理依賴越少越好

提取的流水在該業務邏輯中無實時性依賴

2.3 流水處理完成

因為流水表是放在原數據庫中，而流水處理完成后是操作分庫，如果分庫操作完成去更新老表流水消息，那么又是夸庫事務，如何保證流水狀態的更新和分庫也是在一個事務的？

解決辦法是：在分庫中創建一個流水表，當流失處理完成以后，不是去更新老表狀態，而是插入分庫流水表中、

這樣做的好處：

一般會對流水做唯一索引，那么如果流水重復多次執行的時候，插入分庫流水表的時候肯定由于唯一索引檢測不通過，整個事務就會回滾（當然也可以在處理流水事前應該再做一下冪等性判斷）

這樣通過判斷主庫流水是否在分庫中就能判斷一條流水是否執行完畢

三、流水處理器基本框架

流水處理器其實不包含任何業務相關的處理邏輯，核心功能就是：

• 通知業務接入方何時處理什么樣的流水

• 檢驗流水執行的成功

注：流水執行器并不知道該流水表示什么邏輯，具體需要業務系統去識別后去執行相對應業務邏輯。

3.1 流水執行任務

流水處理調度任務就是通過掃描待處理的流水，然后通知業務系統該執行哪一條流水。

示意圖如下：

3.2 流水校驗任務

流水校驗任務就是要比較主庫和分庫中的流水記錄，對執行未成功的流水通知業務系統進行重新處理，如果多次重試失敗則發出告警。

流程示意圖：

四、為什么不用事務消息

由于是既有項目（互聯網金融，所以是絕對不容忍有任何消息丟失或者消息處理失敗）進行改造，不使用事務消息有1個原因

• 需要額外引入消息隊列，增加系統的復雜度，而且也需要額外的邏輯保證和消息隊列通訊失敗的時候處理

• 其實1不算是主要原因，而是因為事務消息需要手動的commit和rollback（使用數據庫不需要），那么問題來了，spring中事務是有傳遞性的，那我們事務消息何時提交又是個大問題，例如 A.a()本來就是一個事務， 但是另外一個事務B.b()中又調用了A.a() 那事務消息提交是放在A.a()還是B.b()中呢？

看完上述內容，你們對數據庫分庫分表之后該如何解決事務問題有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。