「后端分布式」包括「分布式存儲」和 「分布式計算」兩大類。結合實際工作中碰到的問題，以尋找答案的方式來剖解技術，很多時候我們都不是在創造新技術，而是在應用技術。為了更有效率與效果的用好技術，我們需要了解一些技術的原理與工作方式。帶著問題從使用者的角度去剖析技術原理，并將開源技術產品和框架作為一類技術的參考實現來講解。以講清原理為主要目的，對于具體實現的技術細節若無特別之處則盡可能點到即止。

[[267623]]

事務與復制

近期參與了一個數據分布化相關的項目，涉及到數據庫 MySQL 的數據分布化。簡單來說就是需要在異地數據中心實現多點可寫并保證分布后的數據能達成最終一致性。以前對 MySQL 作數據分布僅僅是讀寫分離，通過數據庫自身的主從復制即可實現寫主庫、讀從庫。現在則需要雙寫主庫并在經歷一個短暫的延時后達成最終一致性，這個問題乍一想比較復雜，但歸根結底還是數據最終一致性的問題。

先回到最簡單的情況，只有一個 MySQL 數據庫時，數據一致性是怎么保證的?了解數據庫的都知道，這是通過數據庫的事務特性來保證的，事務包括四大特性：

• Atomicity 原子性
• Consistency 一致性
• Isolation 隔離性
• Durability 持久性

事務的 ACID 四大特性不是本文重點，就不展開做學術性解說了，不了解的可以在后面參考文獻里[3]去看相關文章。這里只想提一個問題，單一數據庫事務能保證數據的一致性，那么 MySQL 在部署成主從架構時，如何保證主從之間數據的一致性的?

MySQL 為了提供主從復制功能引入了一個新的日志文件叫 binlog，它包含了引發數據變更的事件日志集合。從庫請求主庫發送 binlog 并通過日志事件還原數據寫入從庫，所以從庫的數據來源為 binlog。這樣 MySQL 主庫只需做到 binlog 與本地數據一致就可以保證主從庫數據一致(暫且忽略網絡傳輸引發的主從不一致)。我們知道保證本地數據一致性是靠數據庫事務特性來達成的，而數據庫事務是如何實現的呢?先看下面這張圖：

MySQL 本身不提供事務支持，而是開放了存儲引擎接口，由具體的存儲引擎來實現，具體來說支持 MySQL 事務的存儲引擎就是 InnoDB。存儲引擎實現事務的通用方式是基于 redo log 和 undo log。簡單來說，redo log 記錄事務修改后的數據, undo log 記錄事務前的原始數據。所以當一個事務執行時實際發生過程簡化描述如下：

先記錄 undo/redo log，確保日志刷到磁盤上持久存儲。

更新數據記錄，緩存操作并異步刷盤。

提交事務，在 redo log 中寫入 commit 記錄。

在 MySQL 執行事務過程中如果因故障中斷，可以通過 redo log 來重做事務或通過 undo log 來回滾，確保了數據的一致性。這些都是由事務性存儲引擎來完成的，但 binlog 不在事務存儲引擎范圍內，而是由 MySQL Server 來記錄的。那么就必須保證 binlog 數據和 redo log 之間的一致性，所以開啟了 binlog 后實際的事務執行就多了一步，如下：

先記錄 undo/redo log，確保日志刷到磁盤上持久存儲。

更新數據記錄，緩存操作并異步刷盤。

將事務日志持久化到 binlog。

提交事務，在 redo log 中寫入提交記錄。

這樣的話，只要 binlog 沒寫成功，整個事務是需要回滾的，而 binlog 寫成功后即使 MySQL Crash 了都可以恢復事務并完成提交。要做到這點，就需要把 binlog 和事務關聯起來，而只有保證了 binlog 和事務數據的一致性，才能保證主從數據的一致性。所以 binlog 的寫入過程不得不嵌入到純粹的事務存儲引擎執行過程中，并以內部分布式事務(xa 事務)的方式完成兩階段提交。進一步的細節就不展開了，可以參看后面參考文獻[5]。

總結

我們前面先提出了一個問題，然后從數據一致性的角度去思考，參考了 MySQL 的實現方式。理清并分析了 MySQL 單機環境是如何保證復制機制的數據一致性，也就是 binlog 和事務數據的一致。后面我們才能基于 binlog 這個機制去實現復制并保證主從復制的一致性。主從復制又引入了網絡因素，進一步增加了保證主從數據一致性的復雜度，后面還會撰文進一步分析這個問題。