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

[[267623]]

事務(wù)與復(fù)制

近期參與了一個(gè)數(shù)據(jù)分布化相關(guān)的項(xiàng)目，涉及到數(shù)據(jù)庫 MySQL 的數(shù)據(jù)分布化。簡單來說就是需要在異地?cái)?shù)據(jù)中心實(shí)現(xiàn)多點(diǎn)可寫并保證分布后的數(shù)據(jù)能達(dá)成最終一致性。以前對 MySQL 作數(shù)據(jù)分布僅僅是讀寫分離，通過數(shù)據(jù)庫自身的主從復(fù)制即可實(shí)現(xiàn)寫主庫、讀從庫。現(xiàn)在則需要雙寫主庫并在經(jīng)歷一個(gè)短暫的延時(shí)后達(dá)成最終一致性，這個(gè)問題乍一想比較復(fù)雜，但歸根結(jié)底還是數(shù)據(jù)最終一致性的問題。

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

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

事務(wù)的 ACID 四大特性不是本文重點(diǎn)，就不展開做學(xué)術(shù)性解說了，不了解的可以在后面參考文獻(xiàn)里[3]去看相關(guān)文章。這里只想提一個(gè)問題，單一數(shù)據(jù)庫事務(wù)能保證數(shù)據(jù)的一致性，那么 MySQL 在部署成主從架構(gòu)時(shí)，如何保證主從之間數(shù)據(jù)的一致性的?

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

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

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

更新數(shù)據(jù)記錄，緩存操作并異步刷盤。

提交事務(wù)，在 redo log 中寫入 commit 記錄。

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

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

更新數(shù)據(jù)記錄，緩存操作并異步刷盤。

將事務(wù)日志持久化到 binlog。

提交事務(wù)，在 redo log 中寫入提交記錄。

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

總結(jié)

我們前面先提出了一個(gè)問題，然后從數(shù)據(jù)一致性的角度去思考，參考了 MySQL 的實(shí)現(xiàn)方式。理清并分析了 MySQL 單機(jī)環(huán)境是如何保證復(fù)制機(jī)制的數(shù)據(jù)一致性，也就是 binlog 和事務(wù)數(shù)據(jù)的一致。后面我們才能基于 binlog 這個(gè)機(jī)制去實(shí)現(xiàn)復(fù)制并保證主從復(fù)制的一致性。主從復(fù)制又引入了網(wǎng)絡(luò)因素，進(jìn)一步增加了保證主從數(shù)據(jù)一致性的復(fù)雜度，后面還會撰文進(jìn)一步分析這個(gè)問題。