1. redis集群方案有哪些

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

主從復制 / 主從模式 解決高并發問題

哨兵模式 解決高可用問題

分片集群

2. 主從復制（主從數據同步）

2.1 主從復制定義

主從復制，是指將一臺Redis服務器的數據，復制到其他的Redis服務器。

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

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

Redis主從復制服務器架構圖如下：

2.2 如何搭建主從架構

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

假設我們現在有3臺計算機A、B、C作為Redis節點，我們要用它們來搭建主從架構，把A作為master（主節點）。

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

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

2.3主從復制同步原理

2.3.1 全量同步

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

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

replid和offset

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

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

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

2.3.2 增量同步

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

2.4 主從復制優缺點

優點：解決了系統的高并發讀的問題。
缺點：無法保證系統的高可用，所以哨兵[2]模式出現了。

3. 哨兵模式

3.1 哨兵模式的作用

1、監控

2、自動故障恢復

3、通知redis客戶端

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

監控：Sentinel 會不斷檢查您的master和slave是否按預期工作。

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

通知：Sentinel充當Redis客戶端的服務發現來源，當集群發生故障轉移時，會將最新信息推送給 Redis的客戶端。

3.2 哨兵的監控（心跳機制、選主規則）

3.2.1**Sentinel是如何進行監控的（**心跳機制）

Sentinel基于心跳機制監測服務狀態，每隔1秒向集群的每個實例發送ping命令：

主觀下線：如果某sentinel節點發現某實例未在規定時間響應，則認為該實例主觀下線。

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

3.2.2選主規則

一旦發現主節點客觀下線了。哨兵會推舉新的主節點，選主規則如下：

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

3.3 集群（哨兵模式）腦裂

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

當然如果是哨兵監測不到從節點，則會去除這個從節點

3.3.1 腦裂產生的流程

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

就這樣上圖就存在了兩個主節點，像是大腦分兩列了一樣，且此時客戶端還是連接的第一個master主節點，并繼續寫數據，等到網絡恢復后第一個master會自動把自己變為從節點(我們暫時叫從節點A)如下圖：

從節點A向主節點同步數據時，由于發現數據不一致，就會刪除自己原來的數據，進行同步，造成數據丟失的問題

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

解決方案有兩種，對應著redis的兩個配置參數：

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

如果我們選了第一種解決方案，那么當哨兵聯系不上A節點時，因為A節點沒有slave了，此時數據過來，A節點會拒絕被寫入數據，那么發送數據的服務方就會意識到數據沒有正常發送，之后會采取相應的數據重傳之類的解決方案。

如果我們選了第二種解決方案，那么就相當于限制了一開始A節點的網絡情況，發現網絡情況不好，就拒絕被寫入數據。

其實就是分別針對腦裂時的2個特點：A節點（第一個主節點）網絡有問題，和因為網絡問題導致的和從節點、哨兵斷開聯系而進行的情況判斷，如果發現符合這兩個特點之一，那么就拒絕被寫入數據，防止后來數據丟失。

4.分片集群

4.1 分片集群結構

它的結構特點為：

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

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

客戶端請求可以訪問集群任意節點，經過一定的路由規則，最終都會被轉發到正確節點。

4.2 路由規則

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

4.3 分片集群優缺點

優點：解決了系統的海量數據存儲、高可用、高并發讀寫的問題。
缺點：集群維護很麻煩，而且集群之間的通信和心跳檢測消耗大量的網絡帶寬，無法使用lua腳本和事務。

5. 相關面試題

5.1 Redis集群有哪些方案?

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

主從復制、

哨兵模式、

Redis分片集群

5.2 介紹一下主從同步

單節點Redis的并發能力是有上限的，要進一步提高Redis的并發能力，可以搭建主從集群，實現讀寫分離。一般都是一主多從，主節點負責寫數據，從節點負責讀數據，主節點寫入數據之后，需要把數據同步到從節點中。

5.3 說一下主從同步數據的流程

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

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

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

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

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

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

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

5.4 怎么保證Redis的高并發、高可用

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

詳細回答：

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

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

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

詳細回答：

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

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

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

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

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

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

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

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

5.8 Redis分片集群中數據是怎么存儲和讀取的？

在redis集群中是這樣的

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