一、概述

1. 提升數(shù)據(jù)庫(kù)的并發(fā)能力

• 在實(shí)際工作中，我們常常將Redis作為緩存與MySQL來(lái)配合使用，當(dāng)有請(qǐng)求的時(shí)候，首先會(huì)從緩存中進(jìn)行查找，如果存在就直接取出，如果不存在再訪問(wèn)數(shù)據(jù)庫(kù)。
• 這樣就提升了讀取的效率，也減少了對(duì)后端數(shù)據(jù)庫(kù)的訪問(wèn)壓力。
  
• 此外，對(duì)于一般數(shù)據(jù)庫(kù)應(yīng)用而言，都是讀多寫少的，當(dāng)數(shù)據(jù)庫(kù)讀取數(shù)據(jù)壓力較大時(shí)，我們可以從成本較小的方案開始優(yōu)化，可以首先考慮優(yōu)化SQL和索引，其次就是緩存策略，最后才是主從架構(gòu)。

2. 主從復(fù)制的作用？

• 第一：讀寫分離
  • 在讀多寫少的情況下，可以采用讀寫分離，主庫(kù)當(dāng)做寫庫(kù)，然后根據(jù)實(shí)際需要，選擇使用多個(gè)讀庫(kù)，分散讀的壓力，提高并發(fā)性。
• 第二：數(shù)據(jù)備份
  • 主從復(fù)制其實(shí)就相當(dāng)于一種熱備份的機(jī)制。
• 第三：實(shí)現(xiàn)高可用
  • 數(shù)據(jù)備份其實(shí)就是一種冗余機(jī)制，當(dāng)主服務(wù)器出現(xiàn)故障是時(shí)，可以切換到從服務(wù)器上，提高服務(wù)器可用性。

二、主從復(fù)制原理

• 實(shí)際上主從同步的原理就是基于binlog進(jìn)行數(shù)據(jù)同步的。在主從復(fù)制過(guò)程中，會(huì)基于3個(gè)線程來(lái)操作，一個(gè)主庫(kù)線程，兩個(gè)從庫(kù)線程。
• 二進(jìn)制日志轉(zhuǎn)儲(chǔ)線程是一個(gè)主庫(kù)線程。 當(dāng)從庫(kù)線程連接的時(shí)候，主庫(kù)可以將二進(jìn)制日志發(fā)送給從庫(kù)，當(dāng)主庫(kù)讀取事件的時(shí)候，會(huì)在Binlog上加鎖，讀取完成之后，再將鎖釋放掉。
• 從庫(kù)I/O線程會(huì)連接到主庫(kù)，向主庫(kù)發(fā)送請(qǐng)求更新Binlog。 這時(shí)從庫(kù)的I/O線程就可以讀取到主庫(kù)的二進(jìn)制日志轉(zhuǎn)儲(chǔ)線程發(fā)送的Binlog更新部分，并且拷貝到本地的中繼日志。
• 從庫(kù)SQL線程會(huì)讀取從庫(kù)中的中繼日志，并且執(zhí)行日志中的事件，將從庫(kù)中的數(shù)據(jù)與主庫(kù)保持同步。

• 總結(jié)起來(lái)就是三步：
  • 步驟1：Master將寫操作記錄到二進(jìn)制日志（binlog），這些記錄叫做二進(jìn)制日志事件（binary log events）；
  • 步驟2：Slave 將 Master 的 binary log events拷貝到它的中繼日志（relay log）；
  • 步驟3：Slave重做中繼日志中的事件，將改變應(yīng)用到自己的數(shù)據(jù)庫(kù)中。
    

三、搭建一主一從環(huán)境

前邊的文章已經(jīng)有寫過(guò)，這里就不在復(fù)述了，點(diǎn)擊跳轉(zhuǎn): MySQL主從復(fù)制—有手就能學(xué)會(huì)的MySQL集群搭建教程

四、如何解決數(shù)據(jù)一致性問(wèn)題？

• 進(jìn)行主從同步的內(nèi)容是二進(jìn)制日志，它是一個(gè)文件，在進(jìn)行網(wǎng)絡(luò)傳輸的過(guò)程中就一定會(huì)存在主從延遲，這樣就可能造成用戶在從庫(kù)上讀取的數(shù)據(jù)不是最新的數(shù)據(jù)，也就是主從同步中的數(shù)據(jù)不一致性問(wèn)題。

1. 方案一、異步復(fù)制

• 異步模式就是客戶端提交COMMIT之后不需要等從庫(kù)返回任何結(jié)果，而是直接將結(jié)果返回給客戶端，這樣做的好處是不會(huì)影響主庫(kù)寫的效率。
• 但這樣可能會(huì)存在主庫(kù)宕機(jī)，而Binlog還沒有同步到從庫(kù)的情況，也就是此時(shí)的主庫(kù)和從庫(kù)數(shù)據(jù)不一致。
• 這時(shí)候從從庫(kù)中選擇一個(gè)作為新主，那么新主則可能缺少原來(lái)主服務(wù)器中已提交的事務(wù)。所以，這種復(fù)制模式下的數(shù)據(jù)一致性是最弱的。

2. 方案二、半同步復(fù)制

• 半同步復(fù)制的原理是在客戶端提交COMMIT之后不直接將結(jié)果返回給客戶端，而是等待至少有一個(gè)從庫(kù)接收到了Binlog，并且寫入到中繼日志中，再返回給客戶端。
• 這樣做的好處是提高了數(shù)據(jù)的一致性，當(dāng)然相比于異步復(fù)制來(lái)說(shuō)，至少多增加了一個(gè)網(wǎng)絡(luò)連接的延遲，降低了主庫(kù)寫的效率。
• 在MySQL5.7版本中還增加了一個(gè)參數(shù)，可以對(duì)應(yīng)答的從庫(kù)數(shù)量進(jìn)行設(shè)置，默認(rèn)為1，也就是說(shuō)只要有1個(gè)從庫(kù)進(jìn)行了響應(yīng)，就可以返回給客戶端。如果將這個(gè)參數(shù)調(diào)大，可以提升數(shù)據(jù)一致性的強(qiáng)度，但也會(huì)增加主庫(kù)等待從庫(kù)響應(yīng)的時(shí)間。
  

3. 方案三、組復(fù)制

• 異步復(fù)制和半同步復(fù)制都無(wú)法最終保證數(shù)據(jù)的一致性問(wèn)題，半同步復(fù)制是通過(guò)判斷從庫(kù)響應(yīng)的個(gè)數(shù)來(lái)決定是否返回給客戶端，雖然數(shù)據(jù)一致性相比于異步復(fù)制有提升，但仍然無(wú)法滿足對(duì)數(shù)據(jù)一致性要求高的場(chǎng)景。
• 組復(fù)制技術(shù)MGR很好地彌補(bǔ)了這兩種復(fù)制模式的不足，它是MySQL在5.7.17版本中推出的一種新的數(shù)據(jù)復(fù)制技術(shù)，是基于Paxos協(xié)議的狀態(tài)機(jī)復(fù)制。
• 簡(jiǎn)單說(shuō)一下MGR的工作原理：
• 首先我們將多個(gè)節(jié)點(diǎn)共同組成一個(gè)復(fù)制組，在執(zhí)行讀寫事務(wù)的時(shí)候，需要通過(guò)一致性協(xié)議層的同意，也就是讀寫事務(wù)想要進(jìn)行提交，必須要經(jīng)過(guò)組里“大多數(shù)人”（對(duì)應(yīng)Node節(jié)點(diǎn)）的同意，大多數(shù)指的是同意的節(jié)點(diǎn)數(shù)量需要大于（N／2＋1），這樣才可以進(jìn)行提交，而不是原發(fā)起方一個(gè)說(shuō)了算。
• 而針對(duì)只讀事務(wù)則不需要經(jīng)過(guò)組內(nèi)同意，直接COMMIT即可。
• 在一個(gè)復(fù)制組內(nèi)有多個(gè)節(jié)點(diǎn)組成，它們各自維護(hù)了自己的數(shù)據(jù)副本，并且在一致性協(xié)議層實(shí)現(xiàn)了原子消息和全局有序消息，從而保證組內(nèi)數(shù)據(jù)的一致性。

事實(shí)上，Paxos算法遠(yuǎn)遠(yuǎn)不止這么簡(jiǎn)單，它經(jīng)常被作為分布式一致算法廣泛使用，比如zookeeper就是基于它實(shí)現(xiàn)的，后邊寫到zookeeper時(shí)還會(huì)詳細(xì)分析…文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-424565.html

到了這里，關(guān)于MySQL高級(jí)第十七篇：數(shù)據(jù)庫(kù)主從復(fù)制原理及保證數(shù)據(jù)一致性的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！