1. redis集群方案有哪些

在Redis中提供的集群方案總共有三種（一般一個redis節(jié)點不超過10G內(nèi)存）

主從復(fù)制 / 主從模式 解決高并發(fā)問題

哨兵模式 解決高可用問題

分片集群

2. 主從復(fù)制（主從數(shù)據(jù)同步）

2.1 主從復(fù)制定義

主從復(fù)制，是指將一臺Redis服務(wù)器的數(shù)據(jù)，復(fù)制到其他的Redis服務(wù)器。

前者稱為主節(jié)點(Master)，后者稱為從節(jié)點(Slave)；數(shù)據(jù)的復(fù)制是單向的，只能由主節(jié)點到從節(jié)點。

默認情況下，每臺Redis服務(wù)器都是主節(jié)點；且一個主節(jié)點可以有多個從節(jié)點(或沒有從節(jié)點)，但一個從節(jié)點只能有一個主節(jié)點

Redis主從復(fù)制服務(wù)器架構(gòu)圖如下：

2.2 如何搭建主從架構(gòu)

主從模式是其中最簡單的模式，這種模式中，Redis被分為主節(jié)點（master）和從節(jié)點（slave/replica） 。主節(jié)點可以進行讀、寫操作，而從節(jié)點一般只能進行讀操作，如果在從節(jié)點上進行寫操作，Redis會報錯。主節(jié)點和從節(jié)點會進行數(shù)據(jù)同步，使節(jié)點上的數(shù)據(jù)保持一致。

假設(shè)我們現(xiàn)在有3臺計算機A、B、C作為Redis節(jié)點，我們要用它們來搭建主從架構(gòu)，把A作為master（主節(jié)點）。

① 基本配置：首先，我們要在這3個節(jié)點上都安裝。為保證這3個節(jié)點的Redis狀態(tài)是一樣的，因此把A的Redis配置文件復(fù)制并覆蓋另外兩個節(jié)點的Redis配置文件。然后啟動3個節(jié)點上的Redis。
② 開啟主從關(guān)系：要配置主從可以使用replicaof或者slaveof命令，這兩條命令是一樣的，只是Redis在5.0版本之后把從節(jié)點的名字從slave改成了replica。
有兩種方式可以進行配置：臨時和永久。

永久配置：在從節(jié)點的Redis配置文件（通常是redis.conf）中添加一行配置：slaveof 。其中，后兩個參數(shù)分別是主節(jié)點的ip地址和Redis端口號。
臨時配置：使用redis-cli客戶端連接到redis服務(wù)，執(zhí)行slaveof命令（重啟后失效）：slaveof 。

2.3主從復(fù)制同步原理

2.3.1 全量同步

在6步驟中，master節(jié)點會進行一次bgsave操作生成RDB文件，再把這個RDB文件發(fā)給slave節(jié)點。我們知道，在bgsave期間，Redis仍然能進行服務(wù)，如果在這段時間內(nèi)，master執(zhí)行了寫操作，那么主從節(jié)點之間的數(shù)據(jù)就會產(chǎn)生差異。因此，master節(jié)點會把bgsave執(zhí)行期間的所有命令都記錄到repl_backlog（上圖把名字寫錯了）文件中，然后在發(fā)送RDB文件之后，把repl_backlog中的命令發(fā)送給從節(jié)點（圖中的10操作）。從節(jié)點會執(zhí)行這些命令，從而保證主從間的數(shù)據(jù)是一致的。

Q：一個問題，master是如何得知slave節(jié)點是第一次與它建立連接的呢？
A：關(guān)于這個問題，首先我們要了解兩個概念Replication Id和offset：

replid和offset

**Replication Id：**簡稱replid，是數(shù)據(jù)集的標記，id一致則說明是同一數(shù)據(jù)集。每一個master都有唯一的replid，slave則會繼承master節(jié)點的replid

**offset：**偏移量，隨著記錄在repl_baklog中的數(shù)據(jù)增多而逐漸增大。slave完成同步時也會記錄當(dāng)前同步的offset。如果slave的offset小于master的offset，說明slave數(shù)據(jù)落后于master，需要更新。
slave要進行數(shù)據(jù)同步時，需要告訴master自己的Replication Id和offset。
由于slave原本也是一個master，因此它也有自己的Replication Id和offset，并且和master的不一樣。

master判斷發(fā)現(xiàn)slave發(fā)送來的Replication Id與自己的不一致，說明這是一個全新的slave，就知道要做全量同步了。此外，master會將自己的Replication Id和offset都發(fā)送給這個slave，因此從，經(jīng)過第一次全量同步之后，slave的Replication Id就和master的一樣了。

2.3.2 增量同步

通過bgsave生成RDB是一個比較消耗性能的操作。因此除了第一次做全量同步，其它大多數(shù)時候slave與master都是做增量同步。
增量同步就是只更新slave與master存在差異的部分數(shù)據(jù)（與offset有關(guān)了）。

2.4 主從復(fù)制優(yōu)缺點

優(yōu)點：解決了系統(tǒng)的高并發(fā)讀的問題。
缺點：無法保證系統(tǒng)的高可用，所以哨兵[2]模式出現(xiàn)了。

3. 哨兵模式

3.1 哨兵模式的作用

1、監(jiān)控

2、自動故障恢復(fù)

3、通知redis客戶端

Sentinel在本質(zhì)上是一個獨立的進程。Sentinel的作用如下：

監(jiān)控：Sentinel 會不斷檢查您的master和slave是否按預(yù)期工作。

自動故障恢復(fù)：如果master故障，Sentinel會將一個slave提升為master。當(dāng)故障實例恢復(fù)后也以新的master為主。

通知：Sentinel充當(dāng)Redis客戶端的服務(wù)發(fā)現(xiàn)來源，當(dāng)集群發(fā)生故障轉(zhuǎn)移時，會將最新信息推送給 Redis的客戶端。

3.2 哨兵的監(jiān)控（心跳機制、選主規(guī)則）

3.2.1**Sentinel是如何進行監(jiān)控的（**心跳機制）

Sentinel基于心跳機制監(jiān)測服務(wù)狀態(tài)，每隔1秒向集群的每個實例發(fā)送ping命令：

主觀下線：如果某sentinel節(jié)點發(fā)現(xiàn)某實例未在規(guī)定時間響應(yīng)，則認為該實例主觀下線。

客觀下線：若超過指定數(shù)量（quorum）的sentinel都認為該實例主觀下線，則該實例客觀下線。quorum值最好超過Sentinel實例數(shù)量的一半。

3.2.2選主規(guī)則

一旦發(fā)現(xiàn)主節(jié)點客觀下線了。哨兵會推舉新的主節(jié)點，選主規(guī)則如下：

判斷主與從節(jié)點斷開時間長短，如超過指定值就排除該從節(jié)點
然后判斷從節(jié)點的slave-priority值，越小優(yōu)先級越高
如果slave-prority一樣，則判斷slave節(jié)點的offset值，越大（說明從節(jié)點數(shù)據(jù)與主節(jié)點越相近） 優(yōu)先級越高
最后是判斷slave節(jié)點的運行id大小，越小優(yōu)先級越高。

3.3 集群（哨兵模式）腦裂

如果此時原本的主節(jié)點（暫時稱為A）因為網(wǎng)絡(luò)問題，使得主從節(jié)點處在不同的網(wǎng)絡(luò)分區(qū),哨兵監(jiān)測不到主節(jié)點（沒有回應(yīng)心跳），那么哨兵便會進行選舉出一個新的主節(jié)點（暫時稱為B），這樣就存在了兩個主節(jié)點，像是大腦分兩列了一樣。等A節(jié)點網(wǎng)絡(luò)恢復(fù)之后才會由主節(jié)點降為從節(jié)點。這個過程稱為腦裂。

當(dāng)然如果是哨兵監(jiān)測不到從節(jié)點，則會去除這個從節(jié)點

3.3.1 腦裂產(chǎn)生的流程

上圖是一個正常情況下的哨兵模式，但是由于網(wǎng)絡(luò)問題，沒有回應(yīng)心跳，那么哨兵便會進行選舉出一個新的主節(jié)點（暫時稱為B），這樣就存在了兩個主節(jié)點，像是大腦分兩列了一樣。如下圖：

就這樣上圖就存在了兩個主節(jié)點，像是大腦分兩列了一樣，且此時客戶端還是連接的第一個master主節(jié)點，并繼續(xù)寫數(shù)據(jù)，等到網(wǎng)絡(luò)恢復(fù)后第一個master會自動把自己變?yōu)閺墓?jié)點(我們暫時叫從節(jié)點A)如下圖：

從節(jié)點A向主節(jié)點同步數(shù)據(jù)時，由于發(fā)現(xiàn)數(shù)據(jù)不一致，就會刪除自己原來的數(shù)據(jù)，進行同步，造成數(shù)據(jù)丟失的問題

3.3.2 集群（哨兵模式）腦裂解決方案

解決方案有兩種，對應(yīng)著redis的兩個配置參數(shù)：

1. min-replicas-to-write 1 表示最少的slave節(jié)點為1個
2. min-replicas-max-lag 5 表示數(shù)據(jù)復(fù)制和同步的延遲不能超過5秒

如果我們選了第一種解決方案，那么當(dāng)哨兵聯(lián)系不上A節(jié)點時，因為A節(jié)點沒有slave了，此時數(shù)據(jù)過來，A節(jié)點會拒絕被寫入數(shù)據(jù)，那么發(fā)送數(shù)據(jù)的服務(wù)方就會意識到數(shù)據(jù)沒有正常發(fā)送，之后會采取相應(yīng)的數(shù)據(jù)重傳之類的解決方案。

如果我們選了第二種解決方案，那么就相當(dāng)于限制了一開始A節(jié)點的網(wǎng)絡(luò)情況，發(fā)現(xiàn)網(wǎng)絡(luò)情況不好，就拒絕被寫入數(shù)據(jù)。

其實就是分別針對腦裂時的2個特點：A節(jié)點（第一個主節(jié)點）網(wǎng)絡(luò)有問題，和因為網(wǎng)絡(luò)問題導(dǎo)致的和從節(jié)點、哨兵斷開聯(lián)系而進行的情況判斷，如果發(fā)現(xiàn)符合這兩個特點之一，那么就拒絕被寫入數(shù)據(jù)，防止后來數(shù)據(jù)丟失。

4.分片集群

4.1 分片集群結(jié)構(gòu)

它的結(jié)構(gòu)特點為：

集群中有多個master，每個master保存不同數(shù)據(jù)，且每個master都可以有多個slave節(jié)點。這樣就解決了海量數(shù)據(jù)存儲，高并發(fā)讀寫的問題。相當(dāng)于把主從模式概括進來了。

不再需要哨兵，直接master之間通過ping監(jiān)測彼此健康狀態(tài)。只要超過一定數(shù)量的master節(jié)點認為某個master節(jié)點宕機了，那么那個節(jié)點就客觀下線了。相當(dāng)于變形的哨兵模式。

客戶端請求可以訪問集群任意節(jié)點，經(jīng)過一定的路由規(guī)則，最終都會被轉(zhuǎn)發(fā)到正確節(jié)點。

4.2 路由規(guī)則

Redis 分片集群引入了哈希槽的概念，Redis 集群[3]有 16384 個哈希槽，每個 key通過 CRC16 校驗后對 16384 取模來決定放置哪個槽，集群的每個節(jié)點負責(zé)一部分 hash 槽。這樣能保證客戶端請求不沖突地正確轉(zhuǎn)發(fā)到redis的某個master節(jié)點上。

4.3 分片集群優(yōu)缺點

優(yōu)點：解決了系統(tǒng)的海量數(shù)據(jù)存儲、高可用、高并發(fā)讀寫的問題。
缺點：集群維護很麻煩，而且集群之間的通信和心跳檢測消耗大量的網(wǎng)絡(luò)帶寬，無法使用lua腳本和事務(wù)。

5. 相關(guān)面試題

5.1 Redis集群有哪些方案?

在Redis中提供的集群方案總共有三種：

主從復(fù)制、

哨兵模式、

Redis分片集群

5.2 介紹一下主從同步

單節(jié)點Redis的并發(fā)能力是有上限的，要進一步提高Redis的并發(fā)能力，可以搭建主從集群，實現(xiàn)讀寫分離。一般都是一主多從，主節(jié)點負責(zé)寫數(shù)據(jù)，從節(jié)點負責(zé)讀數(shù)據(jù)，主節(jié)點寫入數(shù)據(jù)之后，需要把數(shù)據(jù)同步到從節(jié)點中。

5.3 說一下主從同步數(shù)據(jù)的流程

主從同步分為了兩個階段，一個是全量同步，一個是增量同步。

全量同步是指從節(jié)點第一次與主節(jié)點建立連接的時候使用全量同步，流程是這樣的：

**第一：**從節(jié)點請求主節(jié)點同步數(shù)據(jù)，其中從節(jié)點會攜帶自己的replication id和offset偏移量。

**第二：**主節(jié)點判斷是否是第一次請求，主要判斷的依據(jù)就是，主節(jié)點與從節(jié)點是否是同一個replication id，如果不是，就說明是第一次同步，那主節(jié)點就會把自己的replication id和offset發(fā)送給從節(jié)點，讓從節(jié)點與主節(jié)點的信息保持一致。

**第三：**在同時主節(jié)點會執(zhí)行bgsave，生成rdb文件后，發(fā)送給從節(jié)點去執(zhí)行，從節(jié)點先把自己的數(shù)據(jù)清空，然后執(zhí)行主節(jié)點發(fā)送過來的rdb文件，這樣就保持了一致。

當(dāng)然，如果在rdb生成執(zhí)行期間，依然有請求到了主節(jié)點，而主節(jié)點會以命令的方式記錄到緩沖區(qū)，緩沖區(qū)是一個日志文件（repl_backlog），最后把這個日志文件發(fā)送給從節(jié)點，這樣就能保證主節(jié)點與從節(jié)點完全一致了，后期再同步數(shù)據(jù)的時候，都是依賴于這個日志文件，這個就是全量同步

增量同步指的是，當(dāng)從節(jié)點服務(wù)重啟之后，數(shù)據(jù)就不一致了，所以這個時候，從節(jié)點會請求主節(jié)點同步數(shù)據(jù)，主節(jié)點還是判斷不是第一次請求，不是第一次就獲取從節(jié)點的offset值，然后主節(jié)點從命令日志中獲取offset值之后的數(shù)據(jù)，發(fā)送給從節(jié)點進行數(shù)據(jù)同步。

5.4 怎么保證Redis的高并發(fā)、高可用

答：使用哨兵模式搭建redis集群

詳細回答：

首先可以搭建主從集群，再加上使用redis中的哨兵模式，哨兵模式可以實現(xiàn)主從集群的自動故障恢復(fù)，里面就包含了對主從服務(wù)的監(jiān)控、自動故障恢復(fù)、通知；如果master故障，Sentinel會將一個slave提升為master。當(dāng)故障實例恢復(fù)后也以新的master為主；同時Sentinel也充當(dāng)Redis客戶端的服務(wù)發(fā)現(xiàn)來源，當(dāng)集群發(fā)生故障轉(zhuǎn)移時，會將最新信息推送給Redis的客戶端，所以一般項目都會采用哨兵的模式來保證redis的高并發(fā)高可用。

5.5 你使用redis是單點還是集群，哪種集群

答：主從（1主1從）+哨兵就可以了。單節(jié)點不超過10G內(nèi)存，如果Redis內(nèi)存不足則可以給不同服務(wù)分配獨立的Redis主從節(jié)點

詳細回答：

候選人：我當(dāng)時使用的是主從（1主1從）加哨兵。一般單節(jié)點不超過10G內(nèi)存，如果Redis內(nèi)存不足則可以給不同服務(wù)分配獨立的Redis主從節(jié)點。盡量不做分片集群。因為集群維護起來比較麻煩，并且集群之間的心跳檢測和數(shù)據(jù)通信會消耗大量的網(wǎng)絡(luò)帶寬，也沒有辦法使用lua腳本和事務(wù)

5.6 redis集群腦裂，該怎么解決呢?

集群腦裂是由于主節(jié)點和從節(jié)點和sentinel處于不同的網(wǎng)絡(luò)分區(qū)，使得sentinel沒有能夠心跳感知到主節(jié)點，所以通過選舉的方式提升了一個從節(jié)點為主，這樣就存在了兩個master，就像大腦分裂了一樣，這樣會導(dǎo)致客戶端還在老的主節(jié)點那里寫入數(shù)據(jù)，新節(jié)點無法同步數(shù)據(jù)，當(dāng)網(wǎng)絡(luò)恢復(fù)后，Sentinel會將老的主節(jié)點降為從節(jié)點，這時再從新master同步數(shù)據(jù)，就會導(dǎo)致數(shù)據(jù)丟失

redis集群腦裂問題，在項目中很少見，不過是這樣解決的

**解決：**我們可以修改redis的配置，可以設(shè)置最少的從節(jié)點數(shù)量以及縮短主從數(shù)據(jù)同步的延遲時間不能超過5秒，達不到要求就拒絕請求，就可以避免大量的數(shù)據(jù)丟失

（如果這里看不懂請重新看 3.3.2）

5.7 redis的分片集群有什么作用

分片集群主要解決的是，海量數(shù)據(jù)存儲的問題，集群中有多個master，每個master保存不同數(shù)據(jù)，并且還可以給每個master設(shè)置多個slave節(jié)點，就可以繼續(xù)增大集群的高并發(fā)能力。同時每個master之間通過ping監(jiān)測彼此健康狀態(tài)，就類似于哨兵模式了。當(dāng)客戶端請求可以訪問集群任意節(jié)點，最終都會被轉(zhuǎn)發(fā)到正確節(jié)點

5.8 Redis分片集群中數(shù)據(jù)是怎么存儲和讀取的？

在redis集群中是這樣的

Redis 集群引入了哈希槽的概念，有 16384 個哈希槽，集群中每個主節(jié)點綁定了一定范圍的哈希槽范圍， key通過 CRC16 校驗后對 16384 取模來決定放置哪個槽，通過槽找到對應(yīng)的節(jié)點進行存儲。