Redis的主從復(fù)制是什么

Redis如何保證高并發(fā)，高可用？

高并發(fā)：redis的單機(jī)吞吐量可以達(dá)到幾萬不是問題，如果想提高redis的讀寫能力，可以用redis的主從架構(gòu)，redis天熱支持一主多從的準(zhǔn)備模式，單主負(fù)責(zé)寫請求多從負(fù)責(zé)讀請求，主從之間異步復(fù)制，把主的數(shù)據(jù)同步到從。

高可用：首先利用redis的主從架構(gòu)解決redis的單點故障導(dǎo)致的不可用，然后如果使用的是主從架構(gòu)，那么只需要增加哨兵機(jī)制即可，就可以實現(xiàn)，redis主實例宕機(jī)，自動會進(jìn)行主備切換。以此來達(dá)到redis的高可用。

你剛才說主從復(fù)制，那你能具體聊一下主從復(fù)制的原理嗎？

在redis主從架構(gòu)中，master負(fù)責(zé)接收寫請求，寫操作成功后返回客戶端OK，然后后將數(shù)據(jù)異步的方式發(fā)送給多個slaver進(jìn)行數(shù)據(jù)同步，不過從redis 2.8開始，slave node會周期性地確認(rèn)自己每次復(fù)制的數(shù)據(jù)量。

當(dāng)啟動一個slave node的時候，它會發(fā)送一個PSYNC命令給master node。如果slave node是重新連接master node，那么master node僅僅會復(fù)制給slave部分缺少的數(shù)據(jù); 否則如果是slave node第一次連接master node，那么會觸發(fā)一次full resynchronization全量復(fù)制。

開始full resynchronization的時候，master會啟動一個后臺線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內(nèi)存（內(nèi)存緩沖區(qū)）中。RDB文件生成完畢之后，master會將這個RDB發(fā)送給slave，slave會先寫入本地磁盤，然后再從本地磁盤加載到內(nèi)存中。然后master會將內(nèi)存中緩存的寫命令發(fā)送給slave，slave也會同步這些數(shù)據(jù)。

另外slave node做復(fù)制的時候，是不會block master node的正常工作的，也不會block對自己的查詢操作，它會用舊的數(shù)據(jù)集來提供服務(wù); 但是復(fù)制完成的時候，需要刪除舊數(shù)據(jù)集，加載新數(shù)據(jù)集，這個時候就會暫停對外服務(wù)了。slave node主要用來進(jìn)行橫向擴(kuò)容，做讀寫分離，擴(kuò)容的slave node可以提高讀的吞吐量。slave與高可用性有很大的關(guān)系。

主從復(fù)制的過程中如果因為網(wǎng)絡(luò)原因停止復(fù)制了會怎么樣？

如果出現(xiàn)網(wǎng)絡(luò)故障斷開連接了，會自動重連的，從redis 2.8開始，就支持主從復(fù)制的斷點續(xù)傳，可以接著上次復(fù)制的地方，繼續(xù)復(fù)制下去，而不是從頭開始復(fù)制一份。

master如果發(fā)現(xiàn)有多個slave node都來重新連接，僅僅會啟動一個rdb save操作，用一份數(shù)據(jù)服務(wù)所有slave node。

master node會在內(nèi)存中創(chuàng)建一個backlog，master和slave都會保存一個replica offset，還有一個master id，offset就是保存在backlog中的。如果master和slave網(wǎng)絡(luò)連接斷掉了，slave會讓master從上次的replica offset開始繼續(xù)復(fù)制。

但是如果沒有找到對應(yīng)的offset，那么就會執(zhí)行一次resynchronization全量復(fù)制。

好的，那你能說說什么是哨兵有什么作用嗎？

哨兵是redis集群架構(gòu)中非常重要的一個組件，主要功能如下
（1）集群監(jiān)控，負(fù)責(zé)監(jiān)控redis master和slave進(jìn)程是否正常工作
（2）消息通知，如果某個redis實例有故障，那么哨兵負(fù)責(zé)發(fā)送消息作為報警通知給管理員
（3）故障轉(zhuǎn)移，如果master node掛掉了，會自動轉(zhuǎn)移到slave node上
（4）配置中心，如果故障轉(zhuǎn)移發(fā)生了，通知client客戶端新的master地址

哨兵本身也是分布式的，作為一個哨兵集群去運行，互相協(xié)同工作
（1）故障轉(zhuǎn)移時，判斷一個master node是宕機(jī)了，需要大部分的哨兵都同意才行，涉及到了分布式選舉的問題
（2）即使部分哨兵節(jié)點掛掉了，哨兵集群還是能正常工作的，因為如果一個作為高可用機(jī)制重要組成部分的故障轉(zhuǎn)移系統(tǒng)本身是單點的，那就很坑爹了。

目前采用的是sentinal 2版本，sentinal 2相對于sentinal 1來說，重寫了很多代碼，主要是讓故障轉(zhuǎn)移的機(jī)制和算法變得更加健壯和簡單。

為什么redis哨兵集群只有2個節(jié)點無法正常工作？

如果兩個哨兵實例，即兩個redis實例，一主一從的模式。

則redis的配置quorum=1，表示一個哨兵認(rèn)為master宕機(jī)即可認(rèn)為master已宕機(jī)。

但是如果是機(jī)器1宕機(jī)了，那哨兵1和master都宕機(jī)了，雖然哨兵2知道m(xù)aster宕機(jī)了，但是這個時候，需要majority，也就是大多數(shù)哨兵都是運行的，2個哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2個哨兵都運行著，就可以允許執(zhí)行故障轉(zhuǎn)移。

但此時哨兵1沒了就只有1個哨兵了了，此時就沒有majority來允許執(zhí)行故障轉(zhuǎn)移，所以故障轉(zhuǎn)移不會執(zhí)行。

主備切換的時候會有數(shù)據(jù)丟失的可能嗎？

會有，而且有兩種可能，一種是異步復(fù)制，一種是腦裂導(dǎo)致的數(shù)據(jù)丟失。

簡單描述一下這兩種數(shù)據(jù)丟失的過程吧

好的，第一種很好理解，因為master 到 slave的復(fù)制是異步的，所以可能有部分?jǐn)?shù)據(jù)還沒復(fù)制到slave的時候，master就宕機(jī)了，此時這些部分?jǐn)?shù)據(jù)就丟失了。雖然master會做持久化，但是哨兵將slave提升為master后，如果舊的master這時候好了，會當(dāng)做slave掛到新的master上，從新的master同步數(shù)據(jù)，原來的數(shù)據(jù)還是會丟失。

第二種，也就是說，某個master所在機(jī)器突然脫離了正常的網(wǎng)絡(luò)，跟其他slave機(jī)器不能連接，但是實際上master還運行著，即集群分區(qū)現(xiàn)象。此時哨兵可能就會認(rèn)為master宕機(jī)了，然后開啟選舉，將其他slave切換成了master.

這個時候，集群里就會有兩個master，也就是所謂的腦裂。

此時雖然某個slave被切換成了master，但是可能client還沒來得及切換到新的master，還繼續(xù)向舊master寫數(shù)據(jù)，這部分?jǐn)?shù)據(jù)可能就丟失了。因此舊master再次恢復(fù)的加入到主從結(jié)構(gòu)中時，會被作為一個slave掛到新的master上去，自己的數(shù)據(jù)會清空，重新從新的master復(fù)制數(shù)據(jù)，原來的寫到舊master的數(shù)據(jù)就丟失了。

那有什么辦法解決這個數(shù)據(jù)丟失的問題嗎？

數(shù)據(jù)丟失的問題是不可避免的，但是我們可以盡量減少。
在redis的配置文件里設(shè)置參數(shù)

min-slaves-to-write 1
min-slaves-max-lag 10

min-slaves-to-write默認(rèn)情況下是0，min-slaves-max-lag默認(rèn)情況下是10。

上面的配置的意思是要求至少有1個slave，數(shù)據(jù)復(fù)制和同步的延遲不能超過10秒。如果說一旦所有的slave，數(shù)據(jù)復(fù)制和同步的延遲都超過了10秒鐘，那么這個時候，master就不會再接收任何請求了。

上面兩個配置可以減少異步復(fù)制和腦裂導(dǎo)致的數(shù)據(jù)丟失。

設(shè)置了這倆參數(shù)具體是怎么減少數(shù)據(jù)丟失的呢？

以上面配置為例，這兩個參數(shù)表示至少有1個salve的與master的同步復(fù)制延遲不能超過10s，一旦所有的slave復(fù)制和同步的延遲達(dá)到了10s，那么此時master就不會接受任何請求。

我們可以減小min-slaves-max-lag參數(shù)的值，這樣就可以避免在發(fā)生故障時大量的數(shù)據(jù)丟失，一旦發(fā)現(xiàn)延遲超過了該值就不會往master中寫入數(shù)據(jù)。

那么對于client，我們可以采取降級措施，將數(shù)據(jù)暫時寫入本地緩存和磁盤中，在一段時間后重新寫入master來保證數(shù)據(jù)不丟失；也可以將數(shù)據(jù)寫入kafka消息隊列，隔一段時間去消費kafka中的數(shù)據(jù)。

通過上面兩個參數(shù)的設(shè)置我們盡可能的減少數(shù)據(jù)的丟失，具體的值還需要在特定的環(huán)境下進(jìn)行測試設(shè)置。