點擊上方藍色字體，選擇“設為星標”

回復”資源“獲取更多資源

大數據技術與架構點擊右側關注，大數據開發領域最強公眾號！

暴走大數據點擊右側關注，暴走大數據！

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

主從復制

介紹

主從復制，是指將一臺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 usernameconfig set masterauth passwordslaveof命令是異步的，不會阻塞。同時，從服務器現有的數據會先被清空，然后才會同步主服務器的數據。?

配置文件

在從服務器配置文件中添加下面的配置然后重啟從服務器即可：#在從節點配置文件中新增下面兩個配置即可指定成為某個主節點的從節點#slaveof 主節點地址 主節點端口slaveof host port#從服務器只讀(推薦配置)slave-read-only yes

使用ACL用戶同步

上一篇文章中介紹了Redis6的新特性ACL訪問控制列表，基于該特性我們可以為Redis設置不同的用戶和權限，在主從復制中我們也可以配置該同步用戶的賬號密碼：#命令行模式#在從節點配置主節點ACL賬號密碼(Redis6開啟ACL的情況)config set masteruser defaultconfig set masterauth wyk123456#在從節點查看主節點的ACL用戶密碼config get master*#配置文件模式 redis.conf#在從節點配置主節點ACL賬號密碼(Redis6開啟ACL的情況)masteruser defaultmasterauth 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-scriptsentinel deny-scripts-reconfig yes

哨兵啟動及驗證

我這里演示在一臺機器上啟動3個Redis服務以及3個哨兵服務，其中3個redis服務作一主兩從，哨兵監控主節點，然后測試主節點掛了之后哨兵自動選舉新的master節點。[實際應用中建議分別部署在不同的機器上]：Redis服務:localhost:6381,localhost:6382,localhost:6383sentinel服務:localhost:26381,localhost:26382,localhost:263836381為Redis初始主節點，6382,6383分別為6381的從節點。26381，26382，26383作為三個哨兵服務監控上面的Redis主從架構。配置啟動三個Redis服務以及Sentinel 服務：1.首先復制Redis目錄出三個：cp -r /opt/app/redis6 /opt/app/redis6Acp -r /opt/app/redis6 /opt/app/redis6Bcp -r /opt/app/redis6 /opt/app/redis6C2.分別修改A,B,C三個目錄中的redis.conf和sentinel.conf文件，主要修改端口和文件路徑，下面以A為演示，B，C略過：vim redis.conf--------------------------------------------port 6381daemonize yespidfile "/var/run/redisA_6381.pid"logfile "/opt/app/redis6A/redis_6381.log" #需要手動touch文件dir "/opt/app/redis6A/data" #需要手動先mkdir文件夾--------------------------------------------vim sentinel.conf--------------------------------------------port 26381daemonize yespidfile /var/run/redis-sentinel_26381.pidlogfile "/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/datamkdir /opt/app/redis6B/datamkdir /opt/app/redis6C/datatouch /opt/app/redis6A/redis_6381.logtouch /opt/app/redis6B/redis_6382.logtouch /opt/app/redis6C/redis_6383.logmkdir /tmp/sentinel_26381mkdir /tmp/sentinel_26382mkdir /tmp/sentinel_26383touch /opt/app/redis6A/sentinel_26381.logtouch /opt/app/redis6B/sentinel_26382.logtouch /opt/app/redis6C/sentinel_26383.log3.配置完成后，分別啟動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時可以使用對應的哨兵接口連接：#JavaJedisSentinelPool#Pythonfrom?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 key1Smart客戶端相比于dummy客戶端，smart客戶端在初始化連接集群時就緩存了槽slot和節點node的對應關系，?也就是在連接任意節點后執行cluster slots，我們使用的JedisCluster就是smart客戶端：cluster slots集群代理：Redis6版本中新增的特性，客戶端不需要知道集群中的具體節點個數和主從身份，可以直接通過代理訪問集群。與Redis在不同的分支，將在后面的文章中具體介紹。?

搭建集群

從Redis5之后我們就可以直接使用redis-cli --cluster命令自動部署Redis集群了，所以本篇也直接使用該方式搭建集群。?這里演示仍然是一臺機器上使用三主三從的方式部署Redis集群：配置：將上面的A,B,C復制出AA,BB,CC，然后修改里面的配置文件：1.首先復制Redis目錄出三個：cp -r /opt/app/redis6A /opt/app/redis6AAcp -r /opt/app/redis6B /opt/app/redis6BBcp -r /opt/app/redis6C /opt/app/redis6CC2.分別修改6個目錄中的redis.conf文件，主要開啟集群以及修改端口和文件路徑，下面以A為演示，其余略過：vim /opt/app/redis6A/bin/redis.conf--------------------------------------------port 6381daemonize yespidfile "/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/datatouch?/opt/app/redis6A/redis_6381.logcluster-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.0主从、哨兵、集群搭建和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。