前言

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

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

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

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

數(shù)據(jù)遷移

數(shù)據(jù)遷移是很容易出故障的一個環(huán)節(jié)，需要考慮怎么更加平滑的遷移舊數(shù)據(jù)到新的數(shù)據(jù)庫和系統(tǒng)，以及達到數(shù)據(jù)準確、快速遷移、減少停機、對業(yè)務(wù)的影響小等，特別是異構(gòu)的數(shù)據(jù)結(jié)構(gòu)情況下，難度更大。

全量

全量遷移的過程如下：

業(yè)務(wù)系統(tǒng)停機。

數(shù)據(jù)庫遷移，校驗數(shù)據(jù)一致性。

然后業(yè)務(wù)系統(tǒng)升級，接入新的數(shù)據(jù)庫。

缺點：

需要業(yè)務(wù)系統(tǒng)停機

遷移時間較長，對業(yè)務(wù)影響較大。如果是異構(gòu)數(shù)據(jù)的話，需要使用程序來處理，遷移時間更長。

全量+增量

全量+增量遷移的方式，需要依賴數(shù)據(jù)本身的創(chuàng)建時間，步驟如下：

先同步數(shù)據(jù)到最近的某個時間戳（創(chuàng)建時間）。

然后發(fā)布系統(tǒng)升級維護的通知。

然后同步最近一段時間變化的數(shù)據(jù)。

最后升級系統(tǒng)，接入新的數(shù)據(jù)庫。

全量+增量的同步相比全量同步的方式，大大的減少了系統(tǒng)停機的時間，對業(yè)務(wù)影響較小。

binlog+全量+增量

binlog+全量+增量是通過從數(shù)據(jù)庫的主庫或者從庫解析和重新構(gòu)造數(shù)據(jù)，實現(xiàn)復(fù)制。

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

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

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

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

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

分布式事務(wù)

XA分布式事務(wù)

XA分布式事務(wù)，是數(shù)據(jù)庫本身支持的協(xié)議，具備強一致性。

XA分布式事務(wù)的組件：

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

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

事務(wù)管理器(Transaction Manager, 簡稱TM): 負責(zé)分配事務(wù)唯一標(biāo)識，監(jiān)控事務(wù)的執(zhí)行進度，并且負責(zé)事務(wù)的提交、回滾等。

XA接口:

xa_start 負責(zé)開啟或者恢復(fù)一個事務(wù)分支

xa_end 負責(zé)取消當(dāng)前線程與事務(wù)分支的關(guān)聯(lián)

xa_prepare 詢問RM是否準備好提交事務(wù)分支

xa_commit 通知RM提交事務(wù)分支

xa_rollback 通知RM回滾事務(wù)分支

xa_recover 需要恢復(fù)的XA事務(wù)

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

完整的XA事務(wù)處理流程如下:

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

XA分布式事務(wù)存在的問題：

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

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

數(shù)據(jù)不一致：極端情況下，會出現(xiàn)事務(wù)失敗問題，需要監(jiān)控和人工處理。即二階段commit請求后，發(fā)送網(wǎng)絡(luò)故障，只有一部分RM收到請求，其他節(jié)點沒有收到Commit請求的情況。

柔性事務(wù)

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

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

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

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

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

BASE柔性事務(wù)常見模式

TCC: 通過手動補償處理

AT: 通過自動補償處理

TCC介紹

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

Try：準備操作，完成所有的業(yè)務(wù)檢查，預(yù)留業(yè)務(wù)資源。

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

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

TCC模型實際是通過業(yè)務(wù)分解來實現(xiàn)分布式事務(wù)，對業(yè)務(wù)有較強的侵入性。

TCC模型需要注意的地方:

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

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

冥等性設(shè)計，即需要保證confirm和cancel需要保證冥等性，防止網(wǎng)絡(luò)因素導(dǎo)致數(shù)據(jù)混亂。

AT

AT模式就是兩階段提交，自動生成反向SQL，當(dāng)發(fā)生異常的時候，通過反向SQL回滾數(shù)據(jù)。

Seata框架對AT的支持如下:

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

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

柔性事務(wù)下的事務(wù)特性

原子性：正常情況下保證

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

隔離性：某個時間點，A能讀到B事務(wù)未提交的結(jié)果，即會臟讀現(xiàn)象。

持久性：和本地事務(wù)一樣，只要commit則數(shù)據(jù)就會被持久化。

總結(jié)

分布式事務(wù)主要目的是解決數(shù)據(jù)一致性問題，XA強一致，但是吞吐量太低，不利于高并發(fā)場景。柔性事務(wù)不保證強一致性，但是通過補償實現(xiàn)最終一致性，常見的補償有重試補償、調(diào)度補償、人工補償?shù)取?/p>

審核編輯 ：李倩