前言

通過對數據的垂直拆分或水平拆分后，我們解決了數據庫容量、性能等問題，但是將會面臨數據遷移和數據一致性的問題。

在數據遷移方面，需要考慮如何快速遷移、平滑遷移、不停機的遷移等。待數據遷移完畢后，還需要校驗數據的完整性。

數據一致性方面，要根據的業務來判斷是否要必要引入分布式事務，如果需要引入分布式事務，需要斟酌是采用XA，還是基于BASE的柔性事務。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

數據遷移

數據遷移是很容易出故障的一個環節，需要考慮怎么更加平滑的遷移舊數據到新的數據庫和系統，以及達到數據準確、快速遷移、減少停機、對業務的影響小等，特別是異構的數據結構情況下，難度更大。

全量

全量遷移的過程如下：

業務系統停機。

數據庫遷移，校驗數據一致性。

然后業務系統升級，接入新的數據庫。

缺點：

需要業務系統停機

遷移時間較長，對業務影響較大。如果是異構數據的話，需要使用程序來處理，遷移時間更長。

全量+增量

全量+增量遷移的方式，需要依賴數據本身的創建時間，步驟如下：

先同步數據到最近的某個時間戳（創建時間）。

然后發布系統升級維護的通知。

然后同步最近一段時間變化的數據。

最后升級系統，接入新的數據庫。

全量+增量的同步相比全量同步的方式，大大的減少了系統停機的時間，對業務影響較小。

binlog+全量+增量

binlog+全量+增量是通過從數據庫的主庫或者從庫解析和重新構造數據，實現復制。

通常情況下都需要中間件等工具的支持，一般需要中間件等工具的支持。可以實現多線程、斷點續傳、全量和增量數據的同步，還可以實現自動擴容和縮容。

常見的工具有：Canal、ShardingSphere-scaling等

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

分布式事務

XA分布式事務

XA分布式事務，是數據庫本身支持的協議，具備強一致性。

XA分布式事務的組件：

應用程序(Application Program, 簡稱AP): 用于定義事務邊界，即事務的開始和結束，并且在事務邊界內對資源進行操作。

資源管理器(Resource Manager, 簡稱RM): 如數據庫、文件系統，并且提供訪問資源的方式。

事務管理器(Transaction Manager, 簡稱TM): 負責分配事務唯一標識，監控事務的執行進度，并且負責事務的提交、回滾等。

XA接口:

xa_start 負責開啟或者恢復一個事務分支

xa_end 負責取消當前線程與事務分支的關聯

xa_prepare 詢問RM是否準備好提交事務分支

xa_commit 通知RM提交事務分支

xa_rollback 通知RM回滾事務分支

xa_recover 需要恢復的XA事務

MySQL從5.0.3開始支持InnoDB引擎的XA分布式事務。

完整的XA事務處理流程如下:

主流的XA框架有：Atomikos、Narayana、Seata

XA分布式事務存在的問題：

同步阻塞：全局事務包含了多個獨立的事務分支，這一組事務分支要么都不成功，要不都失敗，各個分支的ACID特性共同構成了全局事務的ACID特性。如果對讀操作很敏感，需要將數據庫的隔離級別設置為SERIALIZABLE，性能特別的差。

單點故障：TM存在單點故障，需要考慮TM高可用性。

數據不一致：極端情況下，會出現事務失敗問題，需要監控和人工處理。即二階段commit請求后，發送網絡故障，只有一部分RM收到請求，其他節點沒有收到Commit請求的情況。

柔性事務

BASE的核心在于，保證系統基本可用的前提下，通過利用柔性狀態(支付操作后不是支付成功，而是支付中狀態)，實現數據的最終一致性，如下：

基本可用(Basically available)，分布式事務參與方不一定同時在線。

柔性狀態(Soft state), 允許系統狀態更新有一定的延遲，出現一些中間狀態，這個延遲對客戶來說不一定能夠察覺。

最終一致性(Eventually consistent)，通常是通過消息傳遞的方式保證系統的最終一致性。

柔性事務核心理念是通過業務邏輯將互斥鎖操作從RM層上升到業務層，通過放寬對強一致性的要求，來換取系統吞吐量的提升。

BASE柔性事務常見模式

TCC: 通過手動補償處理

AT: 通過自動補償處理

TCC介紹

TCC模式即將每個服務業務操作分成兩個階段，第一個階段檢查并預留相關資源，第二個階段根據所有服務業務的try狀態來操作，如果都成功，則進行Confirm操作，如果任意一個Try發送錯誤，則全部Cancel。

Try：準備操作，完成所有的業務檢查，預留業務資源。

Confirm：真正執行的業務邏輯，不做任意的業務檢查，只使用Try階段預留的業務資源。因此Try操作成功，Confirm必須能成功。同時，Confirm操作必須保證冥等性，保證一筆分布式事務能切只能成功一次。

Cancel：釋放Try階段預留的業務資源，同樣Cancel操作也必須滿足冥等性。

TCC模型實際是通過業務分解來實現分布式事務，對業務有較強的侵入性。

TCC模型需要注意的地方:

允許空回滾，即try沒有完成資源預留，允許短路操作。

防懸掛控制，即需要保證，cancel必須在try之后才執行。

冥等性設計，即需要保證confirm和cancel需要保證冥等性，防止網絡因素導致數據混亂。

AT

AT模式就是兩階段提交，自動生成反向SQL，當發生異常的時候，通過反向SQL回滾數據。

Seata框架對AT的支持如下:

第一階段，業務數據和回滾日志記錄在同一個本地事務中提交，釋放本地鎖和連接資源。

第二階段，提交異步化，非常快速的完成，回滾的話通過一階段的回滾日志進行反向補償。

柔性事務下的事務特性

原子性：正常情況下保證

一致性：某個時間點，數據存在不一致，但是最終是一致的。

隔離性：某個時間點，A能讀到B事務未提交的結果，即會臟讀現象。

持久性：和本地事務一樣，只要commit則數據就會被持久化。

總結

分布式事務主要目的是解決數據一致性問題，XA強一致，但是吞吐量太低，不利于高并發場景。柔性事務不保證強一致性，但是通過補償實現最終一致性，常見的補償有重試補償、調度補償、人工補償等。

審核編輯 ：李倩