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

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

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

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

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

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

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

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

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

2.1 CAP 原則

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

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

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

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

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

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

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

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

那該怎么解決呢？

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

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

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

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

2.2 TCC 一致性方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 實時同步

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

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)主從一致

關于 MySQL 主從復制主要同步的是 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 線程負責讀取 relay log 中的內(nèi)容，解析成具體的操作并執(zhí)行，最終保證主從數(shù)據(jù)的一致性。

3.1.2 API 調用

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

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

1）處理耗時長，需要串行調用多方 API 并等待響應，用戶體驗較差；

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

3.2 異步同步

3.2.1 異步消息隊列

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

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

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

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

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

3.2.2 定時同步

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

常見的定時任務分為 2 種：

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

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

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

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

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

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

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

（1）任何架構方案都是不斷演進的

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

（2）架構的目的是解決業(yè)務問題

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

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

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