目前隨著微服務(wù)化建設(shè)的普及，存在越來越多的跨系統(tǒng)數(shù)據(jù)交互情況，跨系統(tǒng)數(shù)據(jù)一致性問題越發(fā)凸顯，那如何有效保證跨系統(tǒng)數(shù)據(jù)的一致性呢？

本文旨在總結(jié)沉淀工作中問題的解決經(jīng)驗(yàn)，整理解決跨系統(tǒng)數(shù)據(jù)不一致問題的經(jīng)驗(yàn)方法。

1、為什么會(huì)有跨系統(tǒng)數(shù)據(jù)一致性問題？

提到數(shù)據(jù)一致性，我們很容易想到的就是數(shù)據(jù)庫中的事務(wù)操作。

事務(wù)的原子性和持久性可以確保在一個(gè)事務(wù)內(nèi)，操作多條數(shù)據(jù)，要么都成功，要么都失敗。這樣在一個(gè)系統(tǒng)內(nèi)部，我們可以很自然地使用數(shù)據(jù)庫事務(wù)來保證數(shù)據(jù)一致性。但是在微服務(wù)的今天，一項(xiàng)操作會(huì)涉及到跨多個(gè)系統(tǒng)多個(gè)數(shù)據(jù)庫的時(shí)候，用單一的數(shù)據(jù)庫事務(wù)就沒辦法解決了。

另外常見的一種情況就是：存在依賴情況的系統(tǒng)服務(wù)，例如業(yè)務(wù)端與用戶端（業(yè)務(wù)端負(fù)責(zé)生產(chǎn)數(shù)據(jù)，用戶端負(fù)責(zé)展示數(shù)據(jù)），需要數(shù)據(jù)同步來保障跨系統(tǒng)服務(wù)的數(shù)據(jù)一致性，很多時(shí)候采用何種數(shù)據(jù)同步方式，來保障數(shù)據(jù)應(yīng)用的時(shí)效性至關(guān)重要。 

2、一致性問題的難點(diǎn)分析

為了更好的描述和理解問題，我們用一個(gè)案例來闡述：

假設(shè)存在訂單系統(tǒng)與庫存系統(tǒng)，在實(shí)際業(yè)務(wù)中訂單的創(chuàng)建會(huì)伴隨著庫存的減少。兩個(gè)系統(tǒng)為微服務(wù)化部署，其應(yīng)用數(shù)據(jù)也存放在獨(dú)立的數(shù)據(jù)庫中，兩個(gè)系統(tǒng)間通過網(wǎng)絡(luò)進(jìn)行通信。

2.1 CAP 原則

CAP 指的是 Consistency（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性）。

放棄 A （可用性）來保障 CP

具體表現(xiàn)為產(chǎn)生通信故障后，應(yīng)用會(huì)進(jìn)入阻塞狀態(tài)，一直嘗試與庫存系統(tǒng)恢復(fù)通信直到完成所有數(shù)據(jù)處理。這種方案是優(yōu)先保障數(shù)據(jù)完整性，但此方案用戶體驗(yàn)極差，因?yàn)樵谒胁僮魍瓿汕坝脩魰?huì)一直處于等待的狀態(tài)。

CAP 本身就是互斥的，只能從三者中選兩個(gè)，對(duì)于 CA、AP、CP 都有它們自己的應(yīng)用場(chǎng)景，要結(jié)合實(shí)際進(jìn)行選擇。

CA 因?yàn)椴豢紤]分區(qū)容忍度，所以它的所有操作需要在同一進(jìn)程內(nèi)完成（也就是我們常說的單體應(yīng)用）；

AP 因?yàn)榉艞墧?shù)據(jù)一致性，適合數(shù)據(jù)要求不高但強(qiáng)調(diào)用戶體驗(yàn)的項(xiàng)目，如博客、新聞資訊等；

CP 反之放棄了可用性，適合數(shù)據(jù)要求很高的交易系統(tǒng)，如銀行交易、電商的訂單交易等，就算是用戶長(zhǎng)時(shí)間等待，也要保障數(shù)據(jù)的完整可靠。

CAP 原則在實(shí)際項(xiàng)目中的運(yùn)用，對(duì)于互聯(lián)網(wǎng)應(yīng)用來說，如果為了用戶體驗(yàn)完全放棄數(shù)據(jù)一致性這也是不可取的，畢竟數(shù)據(jù)才是應(yīng)用的根本。

那該怎么解決呢？

保障最終一致性的措施有很多，主要包括： 分布式事務(wù)和 TCC 一致性方案 。

MySQL 其實(shí)有一個(gè)兩階段提交的分布式事務(wù)方案（MySQL XA），但是該方案存在嚴(yán)重的性能問題。

比如，一個(gè)數(shù)據(jù)庫的事務(wù)與多個(gè)數(shù)據(jù)庫之間的 XA 事務(wù)性能可能相差 10 倍。另外，在 XA 的事務(wù)處理過程中它會(huì)長(zhǎng)期占用鎖資源，所以一開始我們并不考慮這個(gè)方案。

在此，我們主要討論一下 TCC 一致性方案。

2.2 TCC 一致性方案

TCC 是一種數(shù)據(jù)一致性方案，我們會(huì)把原來的一個(gè)接口分為三個(gè)接口：

• Try 接口用來檢查數(shù)據(jù)、預(yù)留業(yè)務(wù)資源。
• Confirm 接口用來確認(rèn)實(shí)際業(yè)務(wù)操作、更新業(yè)務(wù)資源。
• Cancel 接口是指釋放 Try 接口中預(yù)留的資源。

在 TCC 中，它將分布式處理過程分為兩個(gè)階段：

1、Try 是第一個(gè)階段，用于嘗試并鎖定資源；

2、如果資源鎖定成功，第二個(gè)階段開始進(jìn)行 Confirm 提交完成數(shù)據(jù)操作；

3、如果資源鎖定失敗，第二個(gè)階段就會(huì)進(jìn)行 Cancel 將數(shù)據(jù)回滾；

TCC 實(shí)施過程中有哪些注意事項(xiàng)呢？

1）在 Try 階段做盡可能多的事情

要把絕大多數(shù)的業(yè)務(wù)邏輯在 Try 階段完成，因?yàn)?TCC 設(shè)計(jì)之初認(rèn)為 Confirm 或 Cancel 是一定要成功的，因此不要二階段包含任何業(yè)務(wù)代碼或者遠(yuǎn)程通信，只通過最簡(jiǎn)單的代碼釋放凍結(jié)資源。

2）保障 Confirm 或 Cancel 執(zhí)行成功

假如 Confirm 或 Cancel 執(zhí)行時(shí)出現(xiàn)錯(cuò)誤，那具體應(yīng)用時(shí)也會(huì)不斷重試執(zhí)行操作來盡量保證執(zhí)行成功，這個(gè)過程中可能會(huì)多次執(zhí)行 update 語句，因此要注意代碼的冪等性。

3）Confirm 或 Cancel 執(zhí)行失敗的兜底方案

極小概率下，Confim 或 Cancel 在多次重試后宣告失敗，便會(huì)出現(xiàn)數(shù)據(jù)最終不一致的情況，這就需要自己開發(fā)額外的數(shù)據(jù)完整性校驗(yàn)程序補(bǔ)救或者通過人工進(jìn)行補(bǔ)錄。

TCC 歸根結(jié)底是一種理論設(shè)計(jì)，需要廠商實(shí)現(xiàn)相應(yīng)的框架給予支撐。

在 Java 開源領(lǐng)域著名的 TCC 框架有：ByteTCC、Hmily、Tcc-transaction 與 Seata。

3、有效數(shù)據(jù)同步方案實(shí)踐

問題描述：我們還是以之前的案例場(chǎng)景，數(shù)據(jù)需要從訂單系統(tǒng)同步到庫存系統(tǒng)中。

解決數(shù)據(jù)一致性常用的三類數(shù)據(jù)同步方案： 實(shí)時(shí)同步、定時(shí)同步、手動(dòng)同步 。

3.1 實(shí)時(shí)同步

實(shí)時(shí)同步可以從數(shù)據(jù)庫、應(yīng)用處理兩個(gè)層面來解決。

3.1.1 數(shù)據(jù)庫層面

通用采用數(shù)據(jù)庫的數(shù)據(jù)同步，主從解決，當(dāng) master(主)庫的數(shù)據(jù)發(fā)生變化的時(shí)候，變化會(huì)實(shí)時(shí)的同步到 slave(從)庫。

優(yōu)勢(shì)：

• 水平擴(kuò)展數(shù)據(jù)庫的負(fù)載能力。
• 容錯(cuò)，高可用，F(xiàn)ailover(失敗切換)/High Availability
• 數(shù)據(jù)備份。

如何實(shí)現(xiàn)主從一致

關(guān)于 MySQL 主從復(fù)制主要同步的是 binlog 日志，涉及到三個(gè)線程，一個(gè)運(yùn)行在主節(jié)點(diǎn)（log dump thread），其余兩個(gè)(I/O thread, SQL thread)運(yùn)行在從節(jié)點(diǎn)，如下圖所示: 

（1）主節(jié)點(diǎn) binary log dump 線程

當(dāng)從節(jié)點(diǎn)連接主節(jié)點(diǎn)時(shí)，主節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè) log dump 線程，用于發(fā)送 binlog 的內(nèi)容。在讀取 binlog 中的操作時(shí)，此線程會(huì)對(duì)主節(jié)點(diǎn)上的 binlog 加鎖，當(dāng)讀取完成，在發(fā)送給從節(jié)點(diǎn)之前，鎖會(huì)被釋放。

（2）從節(jié)點(diǎn) I/O 線程

當(dāng)從節(jié)點(diǎn)上執(zhí)行 start slave 命令之后，從節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè) I/O 線程用來連接主節(jié)點(diǎn)，請(qǐng)求主庫中更新的 binlog。I/O 線程接收到主節(jié)點(diǎn) binlog dump 進(jìn)程發(fā)來的更新之后，保存在本地 relay-log（中繼日志）中。

（3）從節(jié)點(diǎn) SQL 線程

SQL 線程負(fù)責(zé)讀取 relay log 中的內(nèi)容，解析成具體的操作并執(zhí)行，最終保證主從數(shù)據(jù)的一致性。

3.1.2 API 調(diào)用

一次業(yè)務(wù)數(shù)據(jù)操作，需要調(diào)用多方 API 實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)的同步。

劣勢(shì)比較明顯，主要表現(xiàn)在：

1）處理耗時(shí)長(zhǎng)，需要串行調(diào)用多方 API 并等待響應(yīng)，用戶體驗(yàn)較差；

2）會(huì)有一定幾率出現(xiàn)數(shù)據(jù)不一致情況（個(gè)別 API 調(diào)用出錯(cuò)、未響應(yīng)等情況）。

3.2 異步同步

3.2.1 異步消息隊(duì)列

Message Queue（MQ），消息隊(duì)列中間件

MQ 通過將消息的發(fā)送和接收分離來實(shí)現(xiàn)應(yīng)用程序的異步和解偶，同時(shí) MQ 屏蔽底層復(fù)雜的通訊協(xié)議，定義了一套應(yīng)用層的、更加簡(jiǎn)單的通訊協(xié)議。

應(yīng)用 MQ 的優(yōu)點(diǎn)：解耦，削峰，數(shù)據(jù)分發(fā)。

在業(yè)務(wù)系統(tǒng)設(shè)計(jì)中，我們常常會(huì)存在一個(gè)平臺(tái)系統(tǒng) A，它關(guān)聯(lián)同步了許許多多的系統(tǒng)的對(duì)接（系統(tǒng) B、C、D 等）。

利用 MQ 可以很好的解決系統(tǒng)對(duì)接和數(shù)據(jù)同步問題，同時(shí)可以忽略對(duì)接系統(tǒng)的穩(wěn)定性等訴求。 

3.2.2 定時(shí)同步

定時(shí)任務(wù)在系統(tǒng)中并不少見，主要目的是用于需要定時(shí)處理數(shù)據(jù)或者執(zhí)行某個(gè)操作的情況下，如定時(shí)關(guān)閉訂單，或者定時(shí)備份。

常見的定時(shí)任務(wù)分為 2 種：

1）第一種：固定時(shí)間執(zhí)行，保障同步并校準(zhǔn)數(shù)據(jù)

如：每分鐘執(zhí)行一次，每天執(zhí)行一次。

2）第二種：延時(shí)多久執(zhí)行，即動(dòng)作發(fā)生后，定時(shí)多久后執(zhí)行任務(wù)

如：15 分鐘后關(guān)閉訂單付款狀態(tài)，24 小時(shí)候后關(guān)閉訂單并且釋放庫存等。

4、應(yīng)用經(jīng)驗(yàn)總結(jié)

技術(shù)還是要解決實(shí)際問題來落地的，應(yīng)用場(chǎng)景很關(guān)鍵，不要單純?yōu)榱思夹g(shù)而技術(shù)，技術(shù)歸根結(jié)底還是為應(yīng)用場(chǎng)景和產(chǎn)業(yè)落地服務(wù)。

軟件設(shè)計(jì)過程中，不需要刻意去應(yīng)用看起來高大上的解決方案，而當(dāng)需要引入時(shí)，要同時(shí)考慮開發(fā)、維護(hù)成本以及對(duì)應(yīng)性能的提升的性價(jià)比，否則得不償失。

（1）任何架構(gòu)方案都是不斷演進(jìn)的

任何數(shù)據(jù)同步本身沒有優(yōu)劣之分，都有其適合的應(yīng)用場(chǎng)景。

（2）架構(gòu)的目的是解決業(yè)務(wù)問題

能夠解決當(dāng)前問題的架構(gòu)方案，同時(shí)兼具易于擴(kuò)展及維護(hù)，那就是一個(gè)優(yōu)秀的架構(gòu)。

隨著互聯(lián)網(wǎng)的告訴發(fā)展，跨系統(tǒng)數(shù)據(jù)一致性應(yīng)用需求一定會(huì)越來越迫切，跨地域跨系統(tǒng)場(chǎng)景的真正痛點(diǎn)也會(huì)越來越清晰，希望我們?cè)诳缦到y(tǒng)數(shù)據(jù)一致性方面的調(diào)研和探索可以給大家一個(gè)思路和參考。

希望今天的講解對(duì)大家有所幫助，謝謝！