前言

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

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

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

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

項(xiàng)目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

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

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

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

全量

全量遷移的過程如下：

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

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

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

缺點(diǎn)：

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

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

全量+增量

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

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

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

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

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

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

binlog+全量+增量

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

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

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

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

項(xiàng)目地址：https://gitee.com/zhijiantianya/yudao-cloud

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

分布式事務(wù)

XA分布式事務(wù)

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

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

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

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

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

XA接口:

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

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

xa_prepare 詢問RM是否準(zhǔn)備好提交事務(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ù)包含了多個(gè)獨(dú)立的事務(wù)分支，這一組事務(wù)分支要么都不成功，要不都失敗，各個(gè)分支的ACID特性共同構(gòu)成了全局事務(wù)的ACID特性。如果對(duì)讀操作很敏感，需要將數(shù)據(jù)庫的隔離級(jí)別設(shè)置為SERIALIZABLE，性能特別的差。

單點(diǎn)故障：TM存在單點(diǎn)故障，需要考慮TM高可用性。

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

柔性事務(wù)

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

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

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

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

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

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

TCC: 通過手動(dòng)補(bǔ)償處理

AT: 通過自動(dòng)補(bǔ)償處理

TCC介紹

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

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

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

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

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

TCC模型需要注意的地方:

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

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

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

AT

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

Seata框架對(duì)AT的支持如下:

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

第二階段，提交異步化，非?？焖俚耐瓿桑貪L的話通過一階段的回滾日志進(jìn)行反向補(bǔ)償。

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

原子性：正常情況下保證

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

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

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

總結(jié)

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

審核編輯 ：李倩