分布式存儲(chǔ)－mysql 數(shù)據(jù)庫(kù)事務(wù)與復(fù)制

作者：Javaspring架構(gòu)師 2019-06-10 14:31:24
存儲(chǔ)
存儲(chǔ)軟件
分布式 結(jié)合實(shí)際工作中碰到的問(wèn)題，以尋找答案的方式來(lái)剖解技術(shù)，很多時(shí)候我們都不是在創(chuàng)造新技術(shù)，而是在應(yīng)用技術(shù)。

創(chuàng)新互聯(lián)主營(yíng)呈貢網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,成都App定制開(kāi)發(fā),呈貢h5小程序設(shè)計(jì)搭建,呈貢網(wǎng)站營(yíng)銷(xiāo)推廣歡迎呈貢等地區(qū)企業(yè)咨詢(xún)

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

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

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

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

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

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

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

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

先記錄 undo/redo log，確保日志刷到磁盤(pán)上持久存儲(chǔ)。

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

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

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

先記錄 undo/redo log，確保日志刷到磁盤(pán)上持久存儲(chǔ)。

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

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

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

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

總結(jié)

我們前面先提出了一個(gè)問(wèn)題，然后從數(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ù)雜度，后面還會(huì)撰文進(jìn)一步分析這個(gè)問(wèn)題。

新聞標(biāo)題：分布式存儲(chǔ)－MySQL數(shù)據(jù)庫(kù)事務(wù)與復(fù)制
URL分享：http://m.fisionsoft.com.cn/article/djidppj.html