點擊上方“Java面試題精選”，關注公眾號

面試刷圖，查缺補漏

>>號外：往期面試題，10篇為一個單位歸置到本公眾號菜單欄->面試題，有需要的歡迎翻閱。

一、概述

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

另一方面，在分庫分表以后還需要保證分庫分表的和主庫的事務一致性。這片文章介紹一下：https://zhuanlan.zhihu.com/p/25933039

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

二、需要解決問題

2.1 原有事務

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

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

2.2 流水

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

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

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

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

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

因此，提取流水的時候:

流水處理越簡單越好

流失處理依賴越少越好

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

2.3 流水處理器

流水處理器即要保證流水處理盡可能處理快，又能保證流水最終能執行成功。

設想一個場景：當出現某一條流水處理失敗，如果流失執行器要等當前流水執行成功才繼續往后執行，那么會影響后續流水的執行，更嚴重的是一直卡在當條記錄，導致整個系統出現問題

因此，流水執行器中設置2個任務：

第一個任務,流水處理任務，已最快的速度執行流水，如果流水處理失敗了，也不影響后面流水處理

第二個任務,流水校驗任務，這個任務就是順序檢查流水記錄，保證所有流水都執行成功，如果失敗，進行重試，多次重試失敗以后發出告警以讓人工介入處理。

2.4 流水處理完成

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

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

這樣做的好處：

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

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

三、流水處理器基本框架

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

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

檢驗流水執行的成功

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

3.1 流水執行任務

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

示意圖如下：

3.2 流水校驗任務

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

流程示意圖：

四、為什么不用事務消息

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

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

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

來源：www.cnblogs.com/lizo/p/8035036.html

最近五期

與其在網上拼命找題？不如馬上關注我們~

總結

以上是生活随笔為你收集整理的mysql分库分表面试_【53期】面试官：谈一下数据库分库分表之后，你是如何解决事务问题？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。