好久沒有寫技術文章了，因為一直在思考 「後端分散式」這個系列到底怎麼寫才合適。
最近基本想清楚了，「後端分散式」包括「分散式儲存」和 「分散式計算」兩大類。
結合實際工作中碰到的問題，以尋找答案的方式來剖解技術，很多時候我們都不是在創造新技術，而是在應用技術。
為了更有效率與效果的用好技術，我們需要了解一些技術的原理與工作方式。
帶著問題從使用者的角度去剖析技術原理，並將開源技術產品和框架作為一類技術的參考實現來講解。
以講清原理為主要目的，對於具體實現的技術細節若無特別之處則儘可能點到即止。

事務與複製

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

先回到最簡單的情況，只有一個 MySQL 資料庫時，資料一致性是怎麼保證的？
瞭解資料庫的都知道，這是通過資料庫的事務特性來保證的，事務包括四大特性：

Atomicity 原子性
Consistency 一致性
Isolation 隔離性
Durability 永續性
事務的 ACID 四大特性不是本文重點，就不展開做學術性解說了，不瞭解的可以在後面參考文獻裡[3]去看相關文章。
這裡只想提一個問題，單一資料庫事務能保證資料的一致性，那麼 MySQL 在部署成主從架構時，如何保證主從之間資料的一致性的？

MySQL 為了提供主從複製功能引入了一個新的日誌檔案叫 binlog，它包含了引發資料變更的事件日誌集合。
從庫請求主庫傳送 binlog 並通過日誌事件還原資料寫入從庫，所以從庫的資料來源為 binlog。
這樣 MySQL 主庫只需做到 binlog 與本地資料一致就可以保證主從庫資料一致（暫且忽略網路傳輸引發的主從不一致）。
我們知道保證本地資料一致性是靠資料庫事務特性來達成的，而資料庫事務是如何實現的呢？先看下面這張圖：

1. 先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
2. 更新資料記錄，快取操作並非同步刷盤。
3. 提交事務，在 redo log 中寫入 commit 記錄。

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

1. 先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
2. 更新資料記錄，快取操作並非同步刷盤。
3. 將事務日誌持久化到 binlog。
4. 提交事務，在 redo log 中寫入提交記錄。

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

總結

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

參考
[1] MySQL Internals Manual. Replication.
[2] MySQL Internals Manual. The Binary Log.
[3] in355hz. 資料庫 ACID 的實現.
[4] jb51. MySQL 對 binlog 的處理說明.
[5] repls. 淺析 innodb_support_xa 與 innodb_flush_log_at_trx_commit.
[6] 68idc. MySQL 5.6 之 DBA 與開發者指南.