在高并發(fā)場(chǎng)景下，數(shù)據(jù)主從同步是必然的方式，除了數(shù)據(jù)庫(kù)主從同步外，還會(huì)涉及到分布式環(huán)境下的數(shù)據(jù)同步。

今天分享數(shù)據(jù)庫(kù)主從同步解決方案。

數(shù)據(jù)主從同步的由來(lái)

互聯(lián)網(wǎng)的很多業(yè)務(wù)，特別是在高并發(fā)的場(chǎng)景下，基本都是讀遠(yuǎn)遠(yuǎn)大于寫(xiě)，如果數(shù)據(jù)庫(kù)讀和寫(xiě)的壓力都同在一臺(tái)主機(jī)上，這顯然不太合理。

于是，把一臺(tái)數(shù)據(jù)庫(kù)主機(jī)分為單獨(dú)的一臺(tái)寫(xiě)主庫(kù)（主要負(fù)責(zé)寫(xiě)操作），而把讀的數(shù)據(jù)庫(kù)壓力分配給讀的從庫(kù)，而且讀從庫(kù)可以變?yōu)槎嗯_(tái)，這就是讀寫(xiě)分離的典型場(chǎng)景如下：

為了進(jìn)一步的降低數(shù)據(jù)庫(kù)端的壓力(高并發(fā)的瓶頸)，這個(gè)時(shí)候也會(huì)在業(yè)務(wù)層部署分布式緩存集群(redis、memcached)等，把讀的壓力轉(zhuǎn)移給應(yīng)用服務(wù)器端，其實(shí)與數(shù)據(jù)主從的設(shè)計(jì)是遵循同一個(gè)原則，降低后端數(shù)據(jù)庫(kù)的壓力。

問(wèn)題：

讀寫(xiě)分離提高了資源的利用效率的同時(shí)也引出了一個(gè)問(wèn)題，就是由于延時(shí)（網(wǎng)絡(luò)傳輸，操作）而引起的數(shù)據(jù)庫(kù)主從不一致的問(wèn)題，以下會(huì)詳細(xì)談相關(guān)的數(shù)據(jù)一致性解決方案。

數(shù)據(jù)同步一致性解決方案

1.半同步復(fù)制

辦法就是等主從同步完成之后，等主庫(kù)上的寫(xiě)請(qǐng)求再返回，這就是常說(shuō)的“半同步復(fù)制"。

實(shí)現(xiàn)方案

mysql的半同步復(fù)制方案，下面我以mysql為例介紹。

MySQL半同步復(fù)制

MySQL的Replication默認(rèn)是一個(gè)異步復(fù)制的過(guò)程，從MySQL5.5開(kāi)始，MySQL以插件的形式支持半同步復(fù)制，我先談下異步復(fù)制，這樣可以更好的理解半同步復(fù)制。

1）異步復(fù)制

MySQL默認(rèn)的復(fù)制是異步的，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后會(huì)立即將結(jié)果返給給客戶端，并不關(guān)心從庫(kù)是否已經(jīng)接收并處理，這樣就會(huì)有一個(gè)問(wèn)題，主如果crash掉了，此時(shí)主上已經(jīng)提交的事務(wù)可能并沒(méi)有傳到從庫(kù)上。

2）半同步復(fù)制

介于異步復(fù)制和全同步復(fù)制之間，主庫(kù)在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫(kù)接收到并寫(xiě)到relay log中才返回給客戶端。相對(duì)于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時(shí)它也造成了一定程度的延遲，這個(gè)延遲最少是一個(gè)TCP/IP往返的時(shí)間。所以，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。

半同步復(fù)制原理：

• 事務(wù)在主庫(kù)寫(xiě)完binlog后需要從庫(kù)返回一個(gè)已接受，才放回給客戶端

• mysql5.5版本以后，以插件的形式存在，需要單獨(dú)安裝

• 確保事務(wù)提交后binlog至少傳輸?shù)揭粋€(gè)從庫(kù)

• 不保證從庫(kù)應(yīng)用完成這個(gè)事務(wù)的binlog

• 性能有一定的降低

• 網(wǎng)絡(luò)異常或從庫(kù)宕機(jī)，卡主庫(kù)，直到超時(shí)或從庫(kù)恢復(fù)

該方案優(yōu)點(diǎn)：

利用數(shù)據(jù)庫(kù)原生功能，比較簡(jiǎn)單

該方案缺點(diǎn)：

主庫(kù)的寫(xiě)請(qǐng)求時(shí)延會(huì)增長(zhǎng)，吞吐量會(huì)降低

2.數(shù)據(jù)庫(kù)中間件

流程：

1）所有的讀寫(xiě)都走數(shù)據(jù)庫(kù)中間件，通常情況下，寫(xiě)請(qǐng)求路由到主庫(kù)，讀請(qǐng)求路由到從庫(kù)

2）記錄所有路由到寫(xiě)庫(kù)的key，在主從同步時(shí)間窗口內(nèi)（假設(shè)是500ms），如果有讀請(qǐng)求訪問(wèn)中間件，此時(shí)有可能從庫(kù)還是舊數(shù)據(jù)，就把這個(gè)key上的讀請(qǐng)求路由到主庫(kù)。

3）在主從同步時(shí)間過(guò)完后，對(duì)應(yīng)key的讀請(qǐng)求繼續(xù)路由到從庫(kù)。

相關(guān)的中間件有：

1）canal:是阿里巴巴旗下的一款開(kāi)源項(xiàng)目，純Java開(kāi)發(fā),基于數(shù)據(jù)庫(kù)增量日志解析，提供增量數(shù)據(jù)訂閱&消費(fèi)，目前主要支持了MySQL。

2）otter：也是阿里開(kāi)源的一個(gè)分布式數(shù)據(jù)庫(kù)同步系統(tǒng)，尤其是在跨機(jī)房數(shù)據(jù)庫(kù)同步方面，有很強(qiáng)大的功能。它是基于數(shù)據(jù)庫(kù)增量日志解析，實(shí)時(shí)將數(shù)據(jù)同步到本機(jī)房或跨機(jī)房的mysql/oracle數(shù)據(jù)庫(kù)。

兩者的區(qū)別在于：

otter目前嵌入式依賴canal，部署為同一個(gè)jvm，目前設(shè)計(jì)為不產(chǎn)生Relay Log。

otter目前允許自定義同步邏輯，解決各類需求。

該方案優(yōu)點(diǎn)

能保證絕對(duì)一致

該方案缺點(diǎn)：

數(shù)據(jù)庫(kù)中間件的成本較高

3.緩存記錄寫(xiě)key法

寫(xiě)流程：

1）如果key要發(fā)生寫(xiě)操作，記錄在cache里，并設(shè)置“經(jīng)驗(yàn)主從同步時(shí)間”的cache超時(shí)時(shí)間，例如500ms

2）然后修改主數(shù)據(jù)庫(kù)

讀流程：

1）先到緩存里查看，對(duì)應(yīng)key有沒(méi)有相關(guān)數(shù)據(jù)

2）有相關(guān)數(shù)據(jù)，說(shuō)明緩存命中，這個(gè)key剛發(fā)生過(guò)寫(xiě)操作，此時(shí)需要將請(qǐng)求路由到主庫(kù)讀最新的數(shù)據(jù)。

3）如果緩存沒(méi)有命中，說(shuō)明這個(gè)key上近期沒(méi)有發(fā)生過(guò)寫(xiě)操作，此時(shí)將請(qǐng)求路由到從庫(kù)，繼續(xù)讀寫(xiě)分離。

該方案優(yōu)點(diǎn)：

相對(duì)數(shù)據(jù)庫(kù)中間件，成本較低

該方案缺點(diǎn)：

為了保證“一致性”，引入了一個(gè)cache組件，并且讀寫(xiě)數(shù)據(jù)庫(kù)時(shí)都多了緩存操作。

以上就是數(shù)據(jù)庫(kù)主從同步一致性方案詳解，如果有興趣了解更加深入的分布式大數(shù)據(jù)分布式文件系統(tǒng)和分布式數(shù)據(jù)庫(kù)的一致性，可以到我的博客mikechen查看：分布式數(shù)據(jù)庫(kù)數(shù)據(jù)一致性的原理、與技術(shù)實(shí)現(xiàn)方案(文章)~

閱讀原文：原文鏈接