分庫分表後，數據庫數據一致性問題如何解決？

前言

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

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

數據一致性方面，要根據的業務來判斷是否要必要引入分佈式事務，如果需要引入分佈式事務，需要斟酌是採用 XA，還是基於 BASE 的柔性事務。

數據遷移

數據遷移是很容易出故障的一個環節，需要考慮怎麼更加平滑的遷移舊數據到新的數據庫和系統，以及達到數據準確、快速遷移、減少停機、對業務的影響小等，特別是異構的數據結構情況下，難度更大。

全量

全量遷移的過程如下：

• 業務系統停機。

• 數據庫遷移，校驗數據一致性。

• 然後業務系統升級，接入新的數據庫。

缺點：

• 需要業務系統停機

• 遷移時間較長，對業務影響較大。如果是異構數據的話，需要使用程序來處理，遷移時間更長。

全量 + 增量

全量 + 增量遷移的方式，需要依賴數據本身的創建時間，步驟如下：

• 先同步數據到最近的某個時間戳（創建時間）。

• 然後發佈系統升級維護的通知。

• 然後同步最近一段時間變化的數據。

• 最後升級系統，接入新的數據庫。

全量 + 增量的同步相比全量同步的方式，大大的減少了系統停機的時間，對業務影響較小。

binlog + 全量 + 增量

binlog + 全量 + 增量是通過從數據庫的主庫或者從庫解析和重新構造數據，實現複製。

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

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

分佈式事務

XA 分佈式事務

XA 分佈式事務，是數據庫本身支持的協議，具備強一致性。

XA 分佈式事務的組件：

• 應用程序 (Application Program, 簡稱 AP): 用於定義事務邊界，即事務的開始和結束，並且在事務邊界內對資源進行操作。

• 資源管理器 (Resource Manager, 簡稱 RM): 如數據庫、文件系統，並且提供訪問資源的方式。

• 事務管理器 (Transaction Manager, 簡稱 TM): 負責分配事務唯一標識，監控事務的執行進度，並且負責事務的提交、回滾等。

XA 接口:

• xa_start 負責開啓或者恢復一個事務分支

• xa_end 負責取消當前線程與事務分支的關聯

• xa_prepare 詢問 RM 是否準備好提交事務分支

• xa_commit 通知 RM 提交事務分支

• xa_rollback 通知 RM 回滾事務分支

• xa_recover 需要恢復的 XA 事務

MySQL 從 5.0.3 開始支持 InnoDB 引擎的 XA 分佈式事務。

完整的 XA 事務處理流程如下:

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

XA 分佈式事務存在的問題：

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

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

• 數據不一致：極端情況下，會出現事務失敗問題，需要監控和人工處理。即二階段 commit 請求後，發送網絡故障，只有一部分 RM 收到請求，其他節點沒有收到 Commit 請求的情況。

柔性事務

BASE 的核心在於，保證系統基本可用的前提下，通過利用柔性狀態 (支付操作後不是支付成功，而是支付中狀態)，實現數據的最終一致性，如下：

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

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

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

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

BASE 柔性事務常見模式

• TCC: 通過手動補償處理

• AT: 通過自動補償處理

TCC 介紹

TCC 模式即將每個服務業務操作分成兩個階段，第一個階段檢查並預留相關資源，第二個階段根據所有服務業務的 try 狀態來操作，如果都成功，則進行 Confirm 操作，如果任意一個 Try 發送錯誤，則全部 Cancel。

• Try：準備操作，完成所有的業務檢查，預留業務資源。

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

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

TCC 模型實際是通過業務分解來實現分佈式事務，對業務有較強的侵入性。

TCC 模型需要注意的地方:

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

• 防懸掛控制，即需要保證，cancel 必須在 try 之後才執行。

• 冥等性設計，即需要保證 confirm 和 cancel 需要保證冥等性，防止網絡因素導致數據混亂。

AT

AT 模式就是兩階段提交，自動生成反向 SQL，當發生異常的時候，通過反向 SQL 回滾數據。

Seata 框架對 AT 的支持如下:

• 第一階段，業務數據和回滾日誌記錄在同一個本地事務中提交，釋放本地鎖和連接資源。

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

柔性事務下的事務特性

• 原子性：正常情況下保證

• 一致性：某個時間點，數據存在不一致，但是最終是一致的。

• 隔離性：某個時間點，A 能讀到 B 事務未提交的結果，即會髒讀現象。

• 持久性：和本地事務一樣，只要 commit 則數據就會被持久化。

總結

分佈式事務主要目的是解決數據一致性問題，XA 強一致，但是吞吐量太低，不利於高併發場景。柔性事務不保證強一致性，但是通過補償實現最終一致性，常見的補償有重試補償、調度補償、人工補償等。

作者：小泥窪

來源：juejin.cn/post/6933003178661462023

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5zjzO1Uk6-qKiQzol0xxZA