一文掌握Redis的三種集羣方案

原文: 一文掌握Redis的三種集羣方案

在開發測試環境中，咱們通常搭建Redis的單實例來應對開發測試需求，可是在生產環境，若是對可用性、可靠性要求較高，則須要引入Redis的集羣方案。雖然如今各大雲平臺有提供緩存服務能夠直接使用，但瞭解一下其背後的實現與原理總仍是有些必要（好比面試），本文就一塊兒來學習一下Redis的幾種集羣方案。html

Redis支持三種集羣方案node

主從複製模式
Sentinel（哨兵）模式
Cluster模式

主從複製模式

1. 基本原理

主從複製模式中包含一個主數據庫實例（master）與一個或多個從數據庫實例（slave），以下圖nginx

客戶端可對主數據庫進行讀寫操做，對從數據庫進行讀操做，主數據庫寫入的數據會實時自動同步給從數據庫。面試

具體工做機制爲：redis

slave啓動後，向master發送SYNC命令，master接收到SYNC命令後經過bgsave保存快照（即上文所介紹的RDB持久化），並使用緩衝區記錄保存快照這段時間內執行的寫命令
master將保存的快照文件發送給slave，並繼續記錄執行的寫命令
slave接收到快照文件後，加載快照文件，載入數據
master快照發送完後開始向slave發送緩衝區的寫命令，slave接收命令並執行，完成複製初始化
此後master每次執行一個寫命令都會同步發送給slave，保持master與slave之間數據的一致性

2. 部署示例

本示例基於Redis 5.0.3版。算法

redis.conf的主要配置shell

###網絡相關###
# bind 127.0.0.1 # 綁定監聽的網卡IP，註釋掉或配置成0.0.0.0可以使任意IP都可訪問
protected-mode no # 關閉保護模式，使用密碼訪問
port 6379  # 設置監聽端口，建議生產環境均使用自定義端口
timeout 30 # 客戶端鏈接空閒多久後斷開鏈接，單位秒，0表示禁用

###通用配置###
daemonize yes # 在後臺運行
pidfile /var/run/redis_6379.pid  # pid進程文件名
logfile /usr/local/redis/logs/redis.log # 日誌文件的位置

###RDB持久化配置###
save 900 1 # 900s內至少一次寫操做則執行bgsave進行RDB持久化
save 300 10
save 60 10000 
# 若是禁用RDB持久化，可在這裏添加 save ""
rdbcompression yes #是否對RDB文件進行壓縮，建議設置爲no，以（磁盤）空間換（CPU）時間
dbfilename dump.rdb # RDB文件名稱
dir /usr/local/redis/datas # RDB文件保存路徑，AOF文件也保存在這裏

###AOF配置###
appendonly yes # 默認值是no，表示不使用AOF增量持久化的方式，使用RDB全量持久化的方式
appendfsync everysec # 可選值 always， everysec，no，建議設置爲everysec

###設置密碼###
requirepass 123456 # 設置複雜一點的密碼

部署主從複製模式只需稍微調整slave的配置，在redis.conf中添加數據庫

replicaof 127.0.0.1 6379 # master的ip，port
masterauth 123456 # master的密碼
replica-serve-stale-data no # 若是slave沒法與master同步，設置成slave不可讀，方便監控腳本發現問題

本示例在單臺服務器上配置master端口6379，兩個slave端口分別爲7001,7002，啓動master，再啓動兩個slave緩存

[root@dev-server-1 master-slave]# redis-server master.conf
[root@dev-server-1 master-slave]# redis-server slave1.conf
[root@dev-server-1 master-slave]# redis-server slave2.conf

進入master數據庫，寫入一個數據，再進入一個slave數據庫，當即即可訪問剛纔寫入master數據庫的數據。以下所示服務器

[root@dev-server-1 master-slave]# redis-cli 
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> set site blog.jboost.cn
OK
127.0.0.1:6379> get site
"blog.jboost.cn"
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1
slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738,lag=0
...
127.0.0.1:6379> exit

[root@dev-server-1 master-slave]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> get site
"blog.jboost.cn"

執行info replication命令能夠查看鏈接該數據庫的其它庫的信息，如上可看到有兩個slave鏈接到master

3. 主從複製的優缺點

優勢：

master能自動將數據同步到slave，能夠進行讀寫分離，分擔master的讀壓力
master、slave之間的同步是以非阻塞的方式進行的，同步期間，客戶端仍然能夠提交查詢或更新請求

缺點：

不具有自動容錯與恢復功能，master或slave的宕機均可能致使客戶端請求失敗，須要等待機器重啓或手動切換客戶端IP才能恢復
master宕機，若是宕機前數據沒有同步完，則切換IP後會存在數據不一致的問題
難以支持在線擴容，Redis的容量受限於單機配置

Sentinel（哨兵）模式

1. 基本原理

哨兵模式基於主從複製模式，只是引入了哨兵來監控與自動處理故障。如圖

哨兵顧名思義，就是來爲Redis集羣站哨的，一旦發現問題能作出相應的應對處理。其功能包括

監控master、slave是否正常運行
當master出現故障時，能自動將一個slave轉換爲master（大哥掛了，選一個小弟上位）
多個哨兵能夠監控同一個Redis，哨兵之間也會自動監控

哨兵模式的具體工做機制：

在配置文件中經過 sentinel monitor <master-name> <ip> <redis-port> <quorum> 來定位master的IP、端口，一個哨兵能夠監控多個master數據庫，只須要提供多個該配置項便可。哨兵啓動後，會與要監控的master創建兩條鏈接：

一條鏈接用來訂閱master的_sentinel_:hello頻道與獲取其餘監控該master的哨兵節點信息
另外一條鏈接按期向master發送INFO等命令獲取master自己的信息

與master創建鏈接後，哨兵會執行三個操做：

按期（通常10s一次，當master被標記爲主觀下線時，改成1s一次）向master和slave發送INFO命令
按期向master和slave的_sentinel_:hello頻道發送本身的信息
按期（1s一次）向master、slave和其餘哨兵發送PING命令

發送INFO命令能夠獲取當前數據庫的相關信息從而實現新節點的自動發現。因此說哨兵只須要配置master數據庫信息就能夠自動發現其slave信息。獲取到slave信息後，哨兵也會與slave創建兩條鏈接執行監控。經過INFO命令，哨兵能夠獲取主從數據庫的最新信息，並進行相應的操做，好比角色變動等。

接下來哨兵向主從數據庫的_sentinel_:hello頻道發送信息與一樣監控這些數據庫的哨兵共享本身的信息，發送內容爲哨兵的ip端口、運行id、配置版本、master名字、master的ip端口還有master的配置版本。這些信息有如下用處：

其餘哨兵能夠經過該信息判斷髮送者是不是新發現的哨兵，若是是的話會建立一個到該哨兵的鏈接用於發送PING命令。
其餘哨兵經過該信息能夠判斷master的版本，若是該版本高於直接記錄的版本，將會更新
當實現了自動發現slave和其餘哨兵節點後，哨兵就能夠經過按期發送PING命令定時監控這些數據庫和節點有沒有中止服務。

若是被PING的數據庫或者節點超時（經過 sentinel down-after-milliseconds master-name milliseconds 配置）未回覆，哨兵認爲其主觀下線（sdown，s就是Subjectively —— 主觀地）。若是下線的是master，哨兵會向其它哨兵發送命令詢問它們是否也認爲該master主觀下線，若是達到必定數目（即配置文件中的quorum）投票，哨兵會認爲該master已經客觀下線（odown，o就是Objectively —— 客觀地），並選舉領頭的哨兵節點對主從系統發起故障恢復。若沒有足夠的sentinel進程贊成master下線，master的客觀下線狀態會被移除，若master從新向sentinel進程發送的PING命令返回有效回覆，master的主觀下線狀態就會被移除

哨兵認爲master客觀下線後，故障恢復的操做須要由選舉的領頭哨兵來執行，選舉採用Raft算法：

發現master下線的哨兵節點（咱們稱他爲A）向每一個哨兵發送命令，要求對方選本身爲領頭哨兵
若是目標哨兵節點沒有選過其餘人，則會贊成選舉A爲領頭哨兵
若是有超過一半的哨兵贊成選舉A爲領頭，則A當選
若是有多個哨兵節點同時參選領頭，此時有可能存在一輪投票無競選者勝出，此時每一個參選的節點等待一個隨機時間後再次發起參選請求，進行下一輪投票競選，直至選舉出領頭哨兵

選出領頭哨兵後，領頭者開始對系統進行故障恢復，從出現故障的master的從數據庫中挑選一個來當選新的master,選擇規則以下：

全部在線的slave中選擇優先級最高的，優先級能夠經過slave-priority配置
若是有多個最高優先級的slave，則選取複製偏移量最大（即複製越完整）的當選
若是以上條件都同樣，選取id最小的slave

挑選出須要繼任的slave後，領頭哨兵向該數據庫發送命令使其升格爲master，而後再向其餘slave發送命令接受新的master，最後更新數據。將已經中止的舊的master更新爲新的master的從數據庫，使其恢復服務後以slave的身份繼續運行。

2. 部署演示

本示例基於Redis 5.0.3版。

哨兵模式基於前文的主從複製模式。哨兵的配置文件爲sentinel.conf，在文件中添加

sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定義一個master數據庫的名稱，後面是master的ip， port，1表示至少須要一個Sentinel進程贊成才能將master判斷爲失效，若是不知足這個條件，則自動故障轉移（failover）不會執行
sentinel auth-pass mymaster 123456 # master的密碼

sentinel down-after-milliseconds mymaster 5000 # 5s未回覆PING，則認爲master主觀下線，默認爲30s
sentinel parallel-syncs mymaster 2  # 指定在執行故障轉移時，最多能夠有多少個slave實例在同步新的master實例，在slave實例較多的狀況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長
sentinel failover-timeout mymaster 300000 # 若是在該時間（ms）內未能完成故障轉移操做，則認爲故障轉移失敗，生產環境須要根據數據量設置該值

一個哨兵能夠監控多個master數據庫，只需按上述配置添加多套

分別以26379,36379,46379端口啓動三個sentinel

[root@dev-server-1 sentinel]# redis-server sentinel1.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel2.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel3.conf --sentinel

也可使用redis-sentinel sentinel1.conf 命令啓動。此時集羣包含一個master、兩個slave、三個sentinel，如圖，

咱們來模擬master掛掉的場景，執行 kill -9 3017 將master進程幹掉，進入slave中執行 info replication查看，

[root@dev-server-1 sentinel]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7002
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
# 省略
127.0.0.1:7001> exit
[root@dev-server-1 sentinel]# redis-cli -p 7002
127.0.0.1:7002> auth 123456
OK
127.0.0.1:7002> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=7001,state=online,offset=13642721,lag=1
# 省略

能夠看到slave 7002已經成功上位晉升爲master（role：master），接收一個slave 7001的鏈接。此時查看slave2.conf配置文件，發現replicaof的配置已經被移除了，slave1.conf的配置文件裏replicaof 127.0.0.1 6379 被改成 replicaof 127.0.0.1 7002。從新啓動master，也能夠看到master.conf配置文件中添加了replicaof 127.0.0.1 7002的配置項，可見大哥（master）下位後，再出來混就只能噹噹小弟（slave）了，三十年河東三十年河西。

3. 哨兵模式的優缺點

優勢：

哨兵模式基於主從複製模式，因此主從複製模式有的優勢，哨兵模式也有
哨兵模式下，master掛掉能夠自動進行切換，系統可用性更高

缺點：

一樣也繼承了主從模式難以在線擴容的缺點，Redis的容量受限於單機配置
須要額外的資源來啓動sentinel進程，實現相對複雜一點，同時slave節點做爲備份節點不提供服務

Cluster模式

1. 基本原理

哨兵模式解決了主從複製不能自動故障轉移，達不到高可用的問題，但仍是存在難以在線擴容，Redis容量受限於單機配置的問題。Cluster模式實現了Redis的分佈式存儲，即每臺節點存儲不一樣的內容，來解決在線擴容的問題。如圖

Cluster採用無中心結構,它的特色以下：

全部的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬
節點的fail是經過集羣中超過半數的節點檢測失效時才生效
客戶端與redis節點直連,不須要中間代理層.客戶端不須要鏈接集羣全部節點,鏈接集羣中任何一個可用節點便可

Cluster模式的具體工做機制：

在Redis的每一個節點上，都有一個插槽（slot），取值範圍爲0-16383
當咱們存取key的時候，Redis會根據CRC16的算法得出一個結果，而後把結果對16384求餘數，這樣每一個key都會對應一個編號在0-16383之間的哈希槽，經過這個值，去找到對應的插槽所對應的節點，而後直接自動跳轉到這個對應的節點上進行存取操做
爲了保證高可用，Cluster模式也引入主從複製模式，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啓用從節點
當其它主節點ping一個主節點A時，若是半數以上的主節點與A通訊超時，那麼認爲主節點A宕機了。若是主節點A和它的從節點都宕機了，那麼該集羣就沒法再提供服務了

Cluster模式集羣節點最小配置6個節點(3主3從，由於須要半數以上)，其中主節點提供讀寫操做，從節點做爲備用節點，不提供請求，只做爲故障轉移使用。

2. 部署演示

本示例基於Redis 5.0.3版。

Cluster模式的部署比較簡單，首先在redis.conf中

port 7100 # 本示例6個節點端口分別爲7100,7200,7300,7400,7500,7600 
daemonize yes # r後臺運行 
pidfile /var/run/redis_7100.pid # pidfile文件對應7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 開啓集羣模式 
masterauth passw0rd # 若是設置了密碼，須要指定master密碼
cluster-config-file nodes_7100.conf # 集羣的配置文件，一樣對應7100,7200等六個節點
cluster-node-timeout 15000 # 請求超時 默認15秒，可自行設置

分別以端口7100,7200,7300,7400,7500,7600 啓動六個實例(若是是每一個服務器一個實例則配置可同樣)

[root@dev-server-1 cluster]# redis-server redis_7100.conf
[root@dev-server-1 cluster]# redis-server redis_7200.conf
...

而後經過命令將這個6個實例組成一個3主節點3從節點的集羣，

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7100 127.0.0.1:7200 127.0.0.1:7300 127.0.0.1:7400 127.0.0.1:7500 127.0.0.1:7600 -a passw0rd

執行結果如圖

能夠看到 7100， 7200， 7300 做爲3個主節點，分配的slot分別爲 0-5460， 5461-10922， 10923-16383， 7600做爲7100的slave， 7500做爲7300的slave，7400做爲7200的slave。

咱們鏈接7100設置一個值

[root@dev-server-1 cluster]# redis-cli -p 7100 -c -a passw0rd
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:7100> set site blog.jboost.cn
-> Redirected to slot [9421] located at 127.0.0.1:7200
OK
127.0.0.1:7200> get site
"blog.jboost.cn"
127.0.0.1:7200>

注意添加 -c 參數表示以集羣模式，不然報 (error) MOVED 9421 127.0.0.1:7200 錯誤，以 -a 參數指定密碼，不然報(error) NOAUTH Authentication required錯誤。

從上面命令看到key爲site算出的slot爲9421，落在7200節點上，因此有Redirected to slot [9421] located at 127.0.0.1:7200，集羣會自動進行跳轉。所以客戶端能夠鏈接任何一個節點來進行數據的存取。

經過cluster nodes可查看集羣的節點信息

127.0.0.1:7200> cluster nodes
eb28aaf090ed1b6b05033335e3d90a202b422d6c 127.0.0.1:7500@17500 slave c1047de2a1b5d5fa4666d554376ca8960895a955 0 1584165266071 5 connected
4cc0463878ae00e5dcf0b36c4345182e021932bc 127.0.0.1:7400@17400 slave 5544aa5ff20f14c4c3665476de6e537d76316b4a 0 1584165267074 4 connected
dbbb6420d64db22f35a9b6fa460b0878c172a2fb 127.0.0.1:7100@17100 master - 0 1584165266000 1 connected 0-5460
d4b434f5829e73e7e779147e905eea6247ffa5a2 127.0.0.1:7600@17600 slave dbbb6420d64db22f35a9b6fa460b0878c172a2fb 0 1584165265000 6 connected
5544aa5ff20f14c4c3665476de6e537d76316b4a 127.0.0.1:7200@17200 myself,master - 0 1584165267000 2 connected 5461-10922
c1047de2a1b5d5fa4666d554376ca8960895a955 127.0.0.1:7300@17300 master - 0 1584165268076 3 connected 10923-16383

咱們將7200經過 kill -9 pid殺死進程來驗證集羣的高可用，從新進入集羣執行cluster nodes能夠看到7200 fail了，可是7400成了master，從新啓動7200，能夠看到此時7200已經變成了slave。

3. Cluster模式的優缺點

優勢：

無中心架構，數據按照slot分佈在多個節點。
集羣中的每一個節點都是平等的關係，每一個節點都保存各自的數據和整個集羣的狀態。每一個節點都和其餘全部節點鏈接，並且這些鏈接保持活躍，這樣就保證了咱們只須要鏈接集羣中的任意一個節點，就能夠獲取到其餘節點的數據。
可線性擴展到1000多個節點，節點可動態添加或刪除
可以實現自動故障轉移，節點之間經過gossip協議交換狀態信息，用投票機制完成slave到master的角色轉換

缺點：

客戶端實現複雜，驅動要求實現Smart Client，緩存slots mapping信息並及時更新，提升了開發難度。目前僅JedisCluster相對成熟，異常處理還不完善，好比常見的「max redirect exception」
節點會由於某些緣由發生阻塞（阻塞時間大於 cluster-node-timeout）被判斷下線，這種failover是沒有必要的
數據經過異步複製，不保證數據的強一致性
slave充當「冷備」，不能緩解讀壓力
批量操做限制，目前只支持具備相同slot值的key執行批量操做，對mset、mget、sunion等操做支持不友好
key事務操做支持有線，只支持多key在同一節點的事務操做，多key分佈不一樣節點時沒法使用事務功能
不支持多數據庫空間，單機redis能夠支持16個db，集羣模式下只能使用一個，即db 0

Redis Cluster模式不建議使用pipeline和multi-keys操做，減小max redirect產生的場景。

總結

本文介紹了Redis集羣方案的三種模式，其中主從複製模式能實現讀寫分離，可是不能自動故障轉移；哨兵模式基於主從複製模式，能實現自動故障轉移，達到高可用，但與主從複製模式同樣，不能在線擴容，容量受限於單機的配置；Cluster模式經過無中心化架構，實現分佈式存儲，可進行線性擴展，也能高可用，但對於像批量操做、事務操做等的支持性不夠好。三種模式各有優缺點，可根據實際場景進行選擇。

參考：

https://blog.csdn.net/q649381130/article/details/79931791
https://www.cnblogs.com/51life/p/10233340.html
https://www.cnblogs.com/chensuqian/p/10538365.html
https://stor.51cto.com/art/201910/604653.htm

做者：空山新雨，一枚仍在學習路上的大齡碼農
近期做者寫了幾十篇技術博客，內容包括Java、Spring Boot、Spring Cloud、Docker，技術管理心得等
歡迎關注做者微信公衆號：空山新雨的技術空間，一塊兒學習成長