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

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

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

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

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

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

2、一致性問題的難點分析

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

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

2.1 CAP 原則

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

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

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

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

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

AP 因為放棄數(shù)據(jù)一致性，適合數(shù)據(jù)要求不高但強調(diào)用戶體驗的項目，如博客、新聞資訊等；

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

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

那該怎么解決呢？

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

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

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

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

2.2 TCC 一致性方案

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

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

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

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

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

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

TCC 實施過程中有哪些注意事項呢？

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

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

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

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

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

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

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

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

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

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

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

3.1 實時同步

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

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

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

優(yōu)勢：

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

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

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

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

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

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

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

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

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

3.1.2 API 調(diào)用

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

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

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

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

3.2 異步同步

3.2.1 異步消息隊列

Message Queue（MQ），消息隊列中間件

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

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

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

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

3.2.2 定時同步

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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