由於單機Redis存儲能力受單機限制，以及無法實現讀寫操作的負載均衡和讀寫分離，無法保證高可用。本篇就來介紹 Redis 集羣搭建方案及實現原理，實現Redis對數據的冗餘備份，從而保證數據和服務的高可用。主從複製是哨兵和集羣的基石，因此我們循序漸進，由淺入深一層層的將Redis高可用方案抽絲剝繭展示在大家面前。

Redis6系列文章：

Redis系列(三)、數據類型之哈希Hash

Redis系列(四)、數據類型之列表List

Redis系列(五)、數據類型之無序集合Set

Redis系列(六)、數據類型之有序集合ZSet(sorted_set)

Redis系列(七)、常用key命令

Redis系列(八)、常用服務器命令

Redis系列(九)、Redis的“事務”及Lua腳本操作

Redis系列(十)、詳解Redis持久化方式AOF、RDB以及混合持久化

Redis系列(十一)、Redis6新特性之ACL安全策略（用戶權限管理）

主從複製

介紹

主從複製，是指將一臺Redis服務器的數據，複製到其他的Redis服務器，主從是哨兵和集羣模式能夠實施的基礎。前者稱爲主節點(master)，後者稱爲從節點(slave),數據的複製是單向的，只能由主節點到從節點。

默認情況下，每臺Redis服務器都是主節點；且一個主節點可以有零個或多個從節點(0+個從節點)，但一個從節點只能有一個主節點。一般主節點負責接收寫請求，從節點負責接收讀請求，從而實現讀寫分離。

主從一般部署在不同機器上，複製時存在網絡延時問題，使用參數repl-disable-tcp-nodelay選擇是否關閉TCP_NODELAY,默認爲關閉：

關閉：無論數據大小都會及時同步到從節點，佔帶寬，適用於主從網絡好的場景；
開啓：主節點每隔指定時間合併數據爲TCP包節省帶寬，默認爲40毫秒同步一次，適用於網絡環境複雜或帶寬緊張，如跨機房；

作用

數據冗餘：主從複製實現了數據的熱備份，是持久化之外的一種數據冗餘方式。
故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務的冗餘。
負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務，分擔服務器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis服務器的併發量。
讀寫分離：主庫寫、從庫讀，讀寫分離不僅可以提高服務器的負載能力，同時可根據需求的變化，改變從庫的數量；
高可用基石：除了上述作用以外，主從複製還是哨兵和集羣能夠實施的基礎。

開啓主從配置

配置主從可以在命令行或配置文件中配置，上面提到主節點負責寫，從節點負責讀，因此推薦開啓從服務器的只讀配置，否則的話在從節點的寫操作不會同步到主節點會導致數據不一致：

命令行模式

在從服務器命令行中執行下面的命令即可成爲該主服務器的從節點：

#在從服務器執行下面的命令成爲或取消成爲某節點的從節點
#slaveof  主服務器的IP  端口號
slaveof  host port

#取消成爲任何服務器的從服務器
slaveof no one

#從服務器只讀(推薦配置)
config set slave-read-only yes

#查看主從信息
info replication

#配置主節點ACL賬號密碼(Redis6開啓ACL的情況)
config set masteruser username
config set masterauth password

slaveof 命令是異步的，不會阻塞。
同時，從服務器現有的數據會先被清空，然後纔會同步主服務器的數據。

配置文件

在從服務器配置文件中添加下面的配置然後重啓從服務器即可：

#在從節點配置文件中新增下面兩個配置即可指定成爲某個主節點的從節點
#slaveof 主節點地址 主節點端口
slaveof  host port

#從服務器只讀(推薦配置)
slave-read-only yes

使用ACL用戶同步

上一篇文章中介紹了Redis6的新特性ACL訪問控制列表，基於該特性我們可以爲Redis設置不同的用戶和權限，在主從複製中我們也可以配置該同步用戶的賬號密碼：

#命令行模式
#在從節點配置主節點ACL賬號密碼(Redis6開啓ACL的情況)
config set masteruser default
config set masterauth wyk123456

#在從節點查看主節點的ACL用戶密碼
config get master*

#配置文件模式 redis.conf
#在從節點配置主節點ACL賬號密碼(Redis6開啓ACL的情況)
masteruser default
masterauth wyk123456

一主一從

最基礎的主從複製模型，主節點負責處理寫請求，從節點負責處理讀請求，主節點使用RDB持久化模式，從節點使用AOF持久化模式：

一主多從

一個主節點可以有多個從節點，但每個從節點只能有一個主節點。一主多從適用於寫少讀多的場景，多個從節點可以分擔讀請求負載，提升併發：

樹狀主從

上面的一主多從可以實現讀請求的負載均衡，但當從節點數量多的時候，主節點的同步壓力也是線性提升的，因此可以使用樹狀主從來分擔主節點的同步壓力：

複製原理

主從複製過程大體可以分爲3個階段：連接建立階段（即準備階段）、數據同步階段、命令傳播階段。

在從節點執行 slaveof 命令後，複製過程便開始按下面的流程運作：

保存主節點信息：配置slaveof之後會在從節點保存主節點的信息。
主從建立socket連接：定時發現主節點以及嘗試建立連接。
發送ping命令：從節點定時發送ping給主節點，主節點返回PONG。若主節點沒有返回PONG或因阻塞無法響應導致超時，則主從斷開，在下次定時任務時會從新ping主節點。
權限驗證：若主節點開啓了ACL或配置了requirepass參數，則從節點需要配置masteruser和masterauth參數才能保證主從正常連接。
同步數據集：首次連接，全量同步。
命令持續複製：全量同步完成後，保持增量同步。

哨兵

介紹

哨兵（sentinel），用於對主從結構中的每一臺服務器進行監控，當主節點出現故障後通過投票機制來挑選新的主節點，並且將所有的從節點連接到新的主節點上。

前面的主從是最基礎的提升Redis服務器穩定性的一種實現方式，但我們可以看到master節點仍然是一臺，若主節點宕機，所有從服務器都不會有新的數據進來，如何讓主節點也實現高可用，當主節點宕機的時候自動從從節點中選舉一臺節點提升爲主節點就是哨兵實現的功能。

作用

監控：監控主從節點運行情況。
通知：當監控節點出現故障，哨兵之間進行通訊。
自動故障轉移：當監控到主節點宕機後，斷開與宕機主節點連接的所有從節點，然後在從節點中選取一個作爲主節點，將其他的從節點連接到這個最新的主節點。最後通知客戶端最新的服務器地址。

哨兵也是一臺redis服務器，只是不對外提供任何服務，redis的bin目錄下的redis-sentinel其實就是redis-server的軟連接。

哨兵節點最少三臺且必須爲單數。這個與其他分佈式框架如zookeeper類似，如果是雙數，在選舉的時候就會出現平票的情況，所以必須是三臺及以上的單數。

配置文件

在redis源碼中找到 sentinel.conf 配置文件，我們把它移動到redis安裝目錄下然後修改配置，共有下面幾個配置：

vim /opt/app/redis6/bin/sentinel.conf

#端口
port 26379

#後臺啓動
daemonize yes

#運行時PID文件
pidfile /var/run/redis-sentinel.pid

#日誌文件(絕對路徑)
logfile "/opt/app/redis6/sentinel.log"

#數據目錄
dir /tmp/sentinel_26379

#監控的節點名字可以自定義，後邊的2代表的：如果有倆個哨兵判斷這個主節點掛了那這個主節點就掛了，通常設置爲哨兵個數一半加一
sentinel monitor mymaster 127.0.0.1 6379 2

#哨兵連接主節點多長時間沒有響應就代表主節點掛了，單位毫秒。默認30000毫秒，30秒。
sentinel down-after-milliseconds mymaster 30000

#在故障轉移時，最多有多少從節點對新的主節點進行同步。這個值越小完成故障轉移的時間就越長，這個值越大就意味着越多的從節點因爲同步數據而暫時阻塞不可用
sentinel parallel-syncs mymaster 1

#在進行同步的過程中，多長時間完成算有效，單位是毫秒，默認值是180000毫秒，3分鐘。
sentinel failover-timeout mymaster 180000

#禁止使用SENTINEL SET設置notification-script和client-reconfig-script
sentinel deny-scripts-reconfig yes

哨兵啓動及驗證

我這裏演示在一臺機器上啓動3個Redis服務以及3個哨兵服務，其中3個redis服務作一主兩從，哨兵監控主節點，然後測試主節點掛了之後哨兵自動選舉新的master節點。[實際應用中建議分別部署在不同的機器上]：

Redis服務:localhost:6381,localhost:6382,localhost:6383
sentinel服務:localhost:26381,localhost:26382,localhost:26383

6381爲Redis初始主節點，6382,6383分別爲6381的從節點。
26381，26382，26383作爲三個哨兵服務監控上面的Redis主從架構。

配置啓動三個Redis服務以及Sentinel 服務：

1.首先複製Redis目錄出三個：
cp -r /opt/app/redis6 /opt/app/redis6A
cp -r /opt/app/redis6 /opt/app/redis6B
cp -r /opt/app/redis6 /opt/app/redis6C

2.分別修改A,B,C三個目錄中的redis.conf和sentinel.conf文件，主要修改端口和文件路徑，下面以A爲演示，B，C略過：
vim redis.conf
--------------------------------------------
port 6381
daemonize yes
pidfile "/var/run/redisA_6381.pid"
logfile "/opt/app/redis6A/redis_6381.log"      #需要手動touch文件
dir "/opt/app/redis6A/data"                    #需要手動先mkdir文件夾
--------------------------------------------

vim sentinel.conf
--------------------------------------------
port 26381
daemonize yes
pidfile /var/run/redis-sentinel_26381.pid
logfile "/opt/app/redis6A/sentinel_26381.log"  #需要手動先touch文件
dir /tmp/sentinel_26381                        #需要手動先mkdir文件夾
sentinel monitor mymaster 127.0.0.1 6381 2     #此參數在ABC三個服務中保持一致，都監聽6381端口
--------------------------------------------

創建log文件和目錄：
mkdir /opt/app/redis6A/data
mkdir /opt/app/redis6B/data
mkdir /opt/app/redis6C/data
touch /opt/app/redis6A/redis_6381.log
touch /opt/app/redis6B/redis_6382.log
touch /opt/app/redis6C/redis_6383.log

mkdir /tmp/sentinel_26381
mkdir /tmp/sentinel_26382
mkdir /tmp/sentinel_26383
touch /opt/app/redis6A/sentinel_26381.log
touch /opt/app/redis6B/sentinel_26382.log
touch /opt/app/redis6C/sentinel_26383.log

3.配置完成後，分別啓動Redis三個服務以及Sentinel三個服務：
#啓動Redis
/opt/app/redis6A/bin/redis-server /opt/app/redis6A/bin/redis.conf
/opt/app/redis6B/bin/redis-server /opt/app/redis6B/bin/redis.conf
/opt/app/redis6C/bin/redis-server /opt/app/redis6C/bin/redis.conf
#配置Redis主從，6381爲主，6382和6383爲從節點

#最後啓動Sentinel
/opt/app/redis6A/bin/redis-sentinel /opt/app/redis6A/bin/sentinel.conf
/opt/app/redis6B/bin/redis-sentinel /opt/app/redis6B/bin/sentinel.conf
/opt/app/redis6C/bin/redis-sentinel /opt/app/redis6C/bin/sentinel.conf

使用redis-cli客戶端命令行進入6381,6382,6383的Redis服務，然後配置6382和6383作爲6381的從節點：

啓動哨兵服務：

此時我們在redis客戶端中使用debug命令模擬主節點崩潰的情況，然後看是否會選舉6382和6383提升爲主節點，以及6381恢復啓動後是什麼角色：

#命令執行一個非法的內存訪問從而讓 Redis 崩潰，僅在開發時用於 BUG 調試，執行後需要重啓服務
debug segfault

然後我們查看哨兵的日誌：

vim /opt/app/redis6A/sentinel_26381.log

重啓6381的redis服務後查看，哨兵已經自動將6381節點作爲6382新主節點的從節點：

原理

哨兵之間會有通訊，哨兵和主從節點之間也有監控，基於這些信息同步和狀態監控實現Redis的故障轉移：

哨兵和哨兵之間以及哨兵和Redis主從節點之間每隔一秒發送ping監控它們的健康狀態；
哨兵向Redis主從節點每隔10秒發送一次info保存節點信息；
哨兵向Redis主節點每隔2秒發送一次hello，直到哨兵報出sdown，代表主節點失聯，然後通知其餘哨兵嘗試連接該主節點；

Redis主節點下線的情況分爲主觀下線和客觀下線：

主觀下線(sdown)：單獨一個哨兵發現master故障了。
客觀下線(odown)：半數哨兵都認爲master節點故障就會觸發故障轉移。

哨兵Leader選舉：

一般情況下當哨兵發現主節點sdown之後該哨兵節點會成爲領導者負責處理主從節點的切換工作：

哨兵A發現Redis主節點失聯；
哨兵A報出sdown，並通知其他哨兵，發送指令sentinel is-master-down-by-address-port給其餘哨兵節點；
其餘哨兵接收到哨兵A的指令後嘗試連接Redis主節點，發現主節點確實失聯；
哨兵返回信息給哨兵A，當超過半數的哨兵認爲主節點下線後，狀態會變成odown；
最先發現主節點下線的哨兵A會成爲哨兵領導者負責這次的主從節點的切換工作；

哨兵的選舉機制是以各哨兵節點接收到發送sentinel is-master-down-by-address-port指令的哨兵id 投票，票數最高的哨兵id會成爲本次故障轉移工作的哨兵Leader；

故障轉移：

當哨兵發現主節點下線之後經過上面的哨兵選舉機制，選舉出本次故障轉移工作的哨兵節點完成本次主從節點切換的工作：

哨兵Leader 根據一定規則從各個從節點中選擇出一個節點升級爲主節點；
其餘從節點修改對應的主節點爲新的主節點；
當原主節點恢復啓動的時候，變爲新的主節點的從節點

哨兵Leader選擇新的主節點遵循下面幾個規則：

健康度：從節點響應時間快；

完整性：從節點消費主節點的offset偏移量儘可能的高 ()；

穩定性：若仍有多個從節點，則根據從節點的創建時間選擇最有資歷的節點升級爲主節點；

在哨兵模式下主從節點總是會變更，因此在Java或Python中訪問哨兵模式下的Redis時可以使用對應的哨兵接口連接：

#Java
JedisSentinelPool

#Python
from redis.sentinel import SentinelConnectionPool

集羣

介紹

Redis集羣(Redis Cluster)是從 Redis 3.0 開始引入的分佈式存儲方案。集羣由多個節點(Node)組成，Redis 的數據分佈在這些節點中。

集羣中的節點分爲主節點和從節點，只有主節點負責讀寫請求和集羣信息的維護，從節點只進行主節點數據和狀態信息的複製。

作用

Redis集羣的作用有下面幾點：

數據分區：突破單機的存儲限制，將數據分散到多個不同的節點存儲；
負載均衡：每個主節點都可以處理讀寫請求，提高了併發能力；
高可用：集羣有着和哨兵模式類似的故障轉移能力，提升集羣的穩定性；

原理

數據分區規則

衡量數據分區方法的標準有兩個重要因素：1) 是否均勻分區; 2)增減節點對數據分佈的影響;

由於哈希算法具有隨機性，可以保證數據均勻分佈，因此Redis集羣採用哈希分區的方式對數據進行分區，哈希分區就是對數據的特徵值進行哈希，然後根據哈希值決定數據放在哪裏。

常見的哈希分區有：

哈希取餘：

計算key的hash值，對節點數量做取餘計算，根據結果將數據映射到對應節點；但當節點增減時，系統中所有數據都需要重新計算映射關係，引發大量數據遷移；

一致性哈希：

將hash值區間抽象爲一個環形，節點均勻分佈在該環形之上，然後根據數據的key計算hash值，在該hash值所在的圓環上的位置延順時針行走找到的第一個節點的位置，該數據就放在該節點之上。相比於哈希取餘，一致性哈希分區將增減節點的影響限制爲相鄰節點。

例：在AB節點中新增一個節點E時，因爲B上的數據的key的hash值在A和B所在的hash區間之內，因此只有C上的一部分數據會遷移到B節點之上；同理如果從BCD中移除C節點，由於C上的數據的key的hash值在B和C所在的hash區間之內，因此C上的數據順時針找到的第一個節點就是D節點，因此C的數據會全部遷移到D節點之上。但當節點數量較少的時候，增刪節點對單個節點的影響較大，會造成數據分佈不均，如移除C節點時，C的數據會全部遷移到D節點上，此時D節點擁有的數據由原來的1/4變成現在的1/2，相比於節點A和B來說負載更高。

帶虛擬節點的一致性哈希 (Redis集羣)：

Redis採用的方案，在一致性哈希基礎之上，引入虛擬節點的概念，虛擬節點被稱爲槽(slot)。Redis集羣中，槽的數量爲16384。

槽介於數據和節點之間，將節點劃分爲一定數量的槽，每個槽包含哈希值一定範圍內的數據。由原來的hash-->node 變爲 hash-->slot-->node。

當增刪節點時，該節點所有擁有的槽會被重新分配給其他節點，可以避免在一致性哈希分區中由於某個節點的增刪造成數據的嚴重分佈不均。

通信機制

在上面的哨兵方案中，節點被分爲數據節點和哨兵節點，哨兵節點也是redis服務，但只作爲選舉監控使用，只有數據節點會存儲數據。而在Redis集羣中，所有節點都是數據節點，也都參與集羣的狀態維護。

在Redis集羣中，數據節點提供兩個TCP端口，在配置防火牆時需要同時開啓下面兩類端口：

普通端口：即客戶端訪問端口，如默認的6379；

集羣端口：普通端口號加10000，如6379的集羣端口爲16379，用於集羣節點之間的通訊；

集羣的節點之間通訊採用Gossip協議，節點根據固定頻率(每秒10次)定時任務進行判斷，當集羣狀態發生變化，如增刪節點、槽狀態變更時，會通過節點間通訊同步集羣狀態，使集羣收斂。

集羣間發送的Gossip消息有下面五種消息類型：

MEET：在節點握手階段，對新加入的節點發送meet消息，請求新節點加入當前集羣，新節點收到消息會回覆PONG消息；
PING：節點之間互相發送ping消息，收到消息的會回覆pong消息。ping消息內容包含本節點和其他節點的狀態信息，以此達到狀態同步；
PONG：pong消息包含自身的狀態數據，在接收到ping或meet消息時會回覆pong消息，也會主動向集羣廣播pong消息；
FAIL：當一個主節點判斷另一個主節點進入fail狀態時，會向集羣廣播這個消息，接收到的節點會保存該消息並對該fail節點做狀態判斷；
PUBLISH：當節點收到publish命令時，會先執行命令，然後向集羣廣播publish消息，接收到消息的節點也會執行publish命令；

訪問集羣

上面介紹了槽的概念，在每個節點存儲着不同範圍的槽，數據也分佈在不同的節點之上，我們在訪問集羣的時候，如何知道數據在哪個節點或者在哪個槽之上呢？下面介紹兩種訪問連接：

Dummy客戶端

使用redis-cli客戶端連接集羣被稱爲dummy客戶端，只會在執行命令之後通過MOVED錯誤重定向找到對應的節點，如圖，我們可以使用redis-cli -c命令進入集羣命令行，當查看或設置key的時候會根據上面提到的CRC16算法計算key的hash值找到對應的槽slot，然後重定向到對應的節點之後才能操作，我們也使用cluster keyslot命令查看key所在的槽solt：

#使用-c進入集羣命令行模式
redis-cli -c -p 6381

#使用命令查看key所在的槽
cluster keyslot key1

Smart客戶端

相比於dummy客戶端，smart客戶端在初始化連接集羣時就緩存了槽slot和節點node的對應關係，也就是在連接任意節點後執行cluster slots，我們使用的JedisCluster就是smart客戶端：

cluster slots

集羣代理：Redis6版本中新增的特性，客戶端不需要知道集羣中的具體節點個數和主從身份，可以直接通過代理訪問集羣。與Redis在不同的分支，將在後面的文章中具體介紹。

搭建集羣

從Redis5之後我們就可以直接使用redis-cli --cluster命令自動部署Redis集羣了，所以本篇也直接使用該方式搭建集羣。

這裏演示仍然是一臺機器上使用三主三從的方式部署Redis集羣：

ID	IP	Host	類型	從節點
A	127.0.0.1	6381	主	AA
B	127.0.0.1	6382	主	BB
C	127.0.0.1	6383	主	CC
AA	127.0.0.1	6391	從	/
BB	127.0.0.1	6392	從	/
CC	127.0.0.1	6393	從	/

配置：

將上面的A,B,C複製出AA,BB,CC，然後修改裏面的配置文件：

1.首先複製Redis目錄出三個：
cp -r /opt/app/redis6A /opt/app/redis6AA
cp -r /opt/app/redis6B /opt/app/redis6BB
cp -r /opt/app/redis6C /opt/app/redis6CC

2.分別修改6個目錄中的redis.conf文件，主要開啓集羣以及修改端口和文件路徑，下面以A爲演示，其餘略過：
vim /opt/app/redis6A/bin/redis.conf
--------------------------------------------
port 6381
daemonize yes
pidfile "/var/run/redisA_6381.pid"
logfile "/opt/app/redis6A/redis_6381.log"      #需要手動touch文件
dir "/opt/app/redis6A/data"                    #需要手動先mkdir文件夾
cluster-enabled yes                            # 啓用集羣模式
cluster-node-timeout 15000                     # 設置當前節點連接超時毫秒數
cluster-config-file node_6381.conf             #設置當前節點集羣配置文件路徑

--------------------------------------------

3.在6個目錄下分別創建log文件和目錄：
mkdir /opt/app/redis6A/data
touch /opt/app/redis6A/redis_6381.log

cluster-config-file：每個節點在運行過程中，會維護一份集羣配置文件。
當集羣信息發生變化時（如增減節點），集羣內所有節點會將最新信息更新到該配置文件。
節點重啓後，會重新讀取該配置文件，獲取集羣信息，可以方便的重新加入到集羣中。
也就是說，當 Redis 節點以集羣模式啓動時，會首先尋找是否有集羣配置文件。
如果有則使用文件中的配置啓動；如果沒有，則初始化配置並將配置保存到文件中。

集羣配置文件由 Redis 節點維護，不需要人工修改。

啓動部署：

部署集羣需要先啓動各個節點的服務，此時這些節點都沒加到集羣中，使用redis-cli --cluster create xxx命令創建集羣：

bin/redis-cli --cluster create 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6391 127.0.0.1:6392 127.0.0.1:6393 --cluster-replicas 1
#這裏的--cluster-replicas表示每個主節點有幾個副本節點

redis-cli --cluster代替了之前的redis-trib.rb，我們無需安裝ruby環境即可直接使用它附帶的所有功能：創建集羣、增刪節點、槽遷移、完整性檢查、數據重平衡等等。

集羣限制

由於Redis集羣中數據分佈在不同的節點上，因此有些功能會受限：

db庫：單機的Redis默認有16個db數據庫，但在集羣模式下只有一個db0；

複製結構：上面的複製結構有樹狀結構，但在集羣模式下只允許單層複製結構；

事務/lua腳本：僅允許操作的key在同一個節點上纔可以在集羣下使用事務或lua腳本；(使用Hash Tag可以解決)

key的批量操作：如mget,mset操作，只有當操作的key都在同一個節點上纔可以執行；(使用Hash Tag可以解決)

keys/flushall：只會在該節點之上進行操作，不會對集羣的其他節點進行操作；

Hash Tag:

上面介紹集羣限制的時候，由於key被分佈在不同的節點之上，因此無法跨節點做事務或lua腳本操作，但我們可以使用hash tag方式解決。

hash tag：當key包含{}的時候，不會對整個key做hash，只會對{}包含的部分做hash然後分配槽slot；因此我們可以讓不同的key在同一個槽內，這樣就可以解決key的批量操作和事務及lua腳本的限制了；

但由於hash tag會將不同的key分配在相同的slot中，如果使用不當，會造成數據分佈不均的情況，需要注意。

集羣參數優化

cluster_node_timeout：默認值爲15s。

影響ping消息接收節點的選擇，值越大對延遲容忍度越高，選擇的接收節點就越少，可以降低帶寬，但會影響收斂速度。應該根據帶寬情況和實際要求具體調整。

影響故障轉移的判定，值越大越不容易誤判，但完成轉移所消耗的時間就越長。應根據網絡情況和實際要求具體調整。

cluster-require-full-coverage

爲了保證集羣的完整性，只有當16384個槽slot全部分配完畢，集羣纔可以上線，但同時，若主節點發生故障且故障轉移還未完成時，原主節點的槽不在任何節點中，集羣會處於下線狀態，影響客戶端的使用。

該參數可以改變此設定：

no: 表示當槽沒有完全分配時，集羣仍然可以上線；

yes: 默認配置，只有槽完全分配，集羣纔可以上線；

希望本文對你有幫助，請點個贊鼓勵一下作者吧~ 謝謝！

Redis系列(十二)、Redis6集羣搭建及原理(主從、哨兵、集羣)

主從複製

介紹

作用

開啓主從配置

命令行模式

配置文件

使用ACL用戶同步

一主一從

一主多從

樹狀主從

複製原理

哨兵

介紹

作用

配置文件

哨兵啓動及驗證

原理

集羣

介紹

作用

原理

數據分區規則

通信機制

訪問集羣

搭建集羣

集羣限制

集羣參數優化

認知提升的方法

螞蟻面試：Springcloud核心組件的底層原理，你知道多少？

Redis系列(十六)、Redis6新特性之IO多線程

Redis系列(十二)、Redis6集羣搭建及原理(主從、哨兵、集羣)

關於ELK，你們想知道的都在這裏了！(Elasticsearch7.7+Logstash7.7+Kibana7.7)

Redis系列(十三)、pub/sub發佈與訂閱（對比List和Kafka）

Redis系列(十五)、Redis6新特性之集羣代理(Cluster Proxy)

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結