目錄
- 主從復(fù)制模式
- 1. 基本原理
- 2. 部署示例
- 3. 主從復(fù)制的優(yōu)缺點(diǎn)
- Sentinel(哨兵)模式
- 1. 基本原理
- 2. 部署演示
- 3. 哨兵模式的優(yōu)缺點(diǎn)
- Cluster模式
- 1. 基本原理
- 2. 部署演示
- 3. Cluster模式的優(yōu)缺點(diǎn)
- 總結(jié)
- 參考:
在開(kāi)發(fā)測(cè)試環(huán)境中,我們一般搭建Redis的單實(shí)例來(lái)應(yīng)對(duì)開(kāi)發(fā)測(cè)試需求,但是在生產(chǎn)環(huán)境,如果對(duì)可用性、可靠性要求較高,則需要引入Redis的集群方案。雖然現(xiàn)在各大云平臺(tái)有提供緩存服務(wù)可以直接使用,但了解一下其背后的實(shí)現(xiàn)與原理總還是有些必要(比如面試), 本文就一起來(lái)學(xué)習(xí)一下Redis的幾種集群方案。
Redis支持三種集群方案
- 主從復(fù)制模式
- Sentinel(哨兵)模式
- Cluster模式
主從復(fù)制模式
1. 基本原理
主從復(fù)制模式中包含一個(gè)主數(shù)據(jù)庫(kù)實(shí)例(master)與一個(gè)或多個(gè)從數(shù)據(jù)庫(kù)實(shí)例(slave),如下圖
客戶端可對(duì)主數(shù)據(jù)庫(kù)進(jìn)行讀寫操作,對(duì)從數(shù)據(jù)庫(kù)進(jìn)行讀操作,主數(shù)據(jù)庫(kù)寫入的數(shù)據(jù)會(huì)實(shí)時(shí)自動(dòng)同步給從數(shù)據(jù)庫(kù)。
具體工作機(jī)制為:
- slave啟動(dòng)后,向master發(fā)送SYNC命令,master接收到SYNC命令后通過(guò)bgsave保存快照(即上文所介紹的RDB持久化),并使用緩沖區(qū)記錄保存快照這段時(shí)間內(nèi)執(zhí)行的寫命令
- master將保存的快照文件發(fā)送給slave,并繼續(xù)記錄執(zhí)行的寫命令
- slave接收到快照文件后,加載快照文件,載入數(shù)據(jù)
- master快照發(fā)送完后開(kāi)始向slave發(fā)送緩沖區(qū)的寫命令,slave接收命令并執(zhí)行,完成復(fù)制初始化
- 此后master每次執(zhí)行一個(gè)寫命令都會(huì)同步發(fā)送給slave,保持master與slave之間數(shù)據(jù)的一致性
2. 部署示例
本示例基于Redis 5.0.3版。
redis.conf的主要配置
###網(wǎng)絡(luò)相關(guān)###
# bind 127.0.0.1 # 綁定監(jiān)聽(tīng)的網(wǎng)卡IP,注釋掉或配置成0.0.0.0可使任意IP均可訪問(wèn)
protected-mode no # 關(guān)閉保護(hù)模式,使用密碼訪問(wèn)
port 6379 # 設(shè)置監(jiān)聽(tīng)端口,建議生產(chǎn)環(huán)境均使用自定義端口
timeout 30 # 客戶端連接空閑多久后斷開(kāi)連接,單位秒,0表示禁用
###通用配置###
daemonize yes # 在后臺(tái)運(yùn)行
pidfile /var/run/redis_6379.pid # pid進(jìn)程文件名
logfile /usr/local/redis/logs/redis.log # 日志文件的位置
###RDB持久化配置###
save 900 1 # 900s內(nèi)至少一次寫操作則執(zhí)行bgsave進(jìn)行RDB持久化
save 300 10
save 60 10000
# 如果禁用RDB持久化,可在這里添加 save ""
rdbcompression yes #是否對(duì)RDB文件進(jìn)行壓縮,建議設(shè)置為no,以(磁盤)空間換(CPU)時(shí)間
dbfilename dump.rdb # RDB文件名稱
dir /usr/local/redis/datas # RDB文件保存路徑,AOF文件也保存在這里
###AOF配置###
appendonly yes # 默認(rèn)值是no,表示不使用AOF增量持久化的方式,使用RDB全量持久化的方式
appendfsync everysec # 可選值 always, everysec,no,建議設(shè)置為everysec
###設(shè)置密碼###
requirepass 123456 # 設(shè)置復(fù)雜一點(diǎn)的密碼
部署主從復(fù)制模式只需稍微調(diào)整slave的配置,在redis.conf中添加
replicaof 127.0.0.1 6379 # master的ip,port
masterauth 123456 # master的密碼
replica-serve-stale-data no # 如果slave無(wú)法與master同步,設(shè)置成slave不可讀,方便監(jiān)控腳本發(fā)現(xiàn)問(wèn)題
本示例在單臺(tái)服務(wù)器上配置master端口6379,兩個(gè)slave端口分別為7001,7002,啟動(dòng)master,再啟動(dòng)兩個(gè)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
進(jìn)入master數(shù)據(jù)庫(kù),寫入一個(gè)數(shù)據(jù),再進(jìn)入一個(gè)slave數(shù)據(jù)庫(kù),立即便可訪問(wèn)剛才寫入master數(shù)據(jù)庫(kù)的數(shù)據(jù)。如下所示
[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"
執(zhí)行info replication
命令可以查看連接該數(shù)據(jù)庫(kù)的其它庫(kù)的信息,如上可看到有兩個(gè)slave連接到master
3. 主從復(fù)制的優(yōu)缺點(diǎn)
優(yōu)點(diǎn):
- master能自動(dòng)將數(shù)據(jù)同步到slave,可以進(jìn)行讀寫分離,分擔(dān)master的讀壓力
- master、slave之間的同步是以非阻塞的方式進(jìn)行的,同步期間,客戶端仍然可以提交查詢或更新請(qǐng)求
缺點(diǎn):
- 不具備自動(dòng)容錯(cuò)與恢復(fù)功能,master或slave的宕機(jī)都可能導(dǎo)致客戶端請(qǐng)求失敗,需要等待機(jī)器重啟或手動(dòng)切換客戶端IP才能恢復(fù)
- master宕機(jī),如果宕機(jī)前數(shù)據(jù)沒(méi)有同步完,則切換IP后會(huì)存在數(shù)據(jù)不一致的問(wèn)題
- 難以支持在線擴(kuò)容,Redis的容量受限于單機(jī)配置
Sentinel(哨兵)模式
1. 基本原理
哨兵模式基于主從復(fù)制模式,只是引入了哨兵來(lái)監(jiān)控與自動(dòng)處理故障。如圖
哨兵顧名思義,就是來(lái)為Redis集群站哨的,一旦發(fā)現(xiàn)問(wèn)題能做出相應(yīng)的應(yīng)對(duì)處理。其功能包括
- 監(jiān)控master、slave是否正常運(yùn)行
- 當(dāng)master出現(xiàn)故障時(shí),能自動(dòng)將一個(gè)slave轉(zhuǎn)換為master(大哥掛了,選一個(gè)小弟上位)
- 多個(gè)哨兵可以監(jiān)控同一個(gè)Redis,哨兵之間也會(huì)自動(dòng)監(jiān)控
哨兵模式的具體工作機(jī)制:
在配置文件中通過(guò) sentinel monitor master-name> ip> redis-port> quorum>
來(lái)定位master的IP、端口,一個(gè)哨兵可以監(jiān)控多個(gè)master數(shù)據(jù)庫(kù),只需要提供多個(gè)該配置項(xiàng)即可。哨兵啟動(dòng)后,會(huì)與要監(jiān)控的master建立兩條連接:
- 一條連接用來(lái)訂閱master的
_sentinel_:hello
頻道與獲取其他監(jiān)控該master的哨兵節(jié)點(diǎn)信息
- 另一條連接定期向master發(fā)送INFO等命令獲取master本身的信息
與master建立連接后,哨兵會(huì)執(zhí)行三個(gè)操作:
- 定期(一般10s一次,當(dāng)master被標(biāo)記為主觀下線時(shí),改為1s一次)向master和slave發(fā)送INFO命令
- 定期向master和slave的
_sentinel_:hello
頻道發(fā)送自己的信息
- 定期(1s一次)向master、slave和其他哨兵發(fā)送PING命令
發(fā)送INFO命令可以獲取當(dāng)前數(shù)據(jù)庫(kù)的相關(guān)信息從而實(shí)現(xiàn)新節(jié)點(diǎn)的自動(dòng)發(fā)現(xiàn)。所以說(shuō)哨兵只需要配置master數(shù)據(jù)庫(kù)信息就可以自動(dòng)發(fā)現(xiàn)其slave信息。獲取到slave信息后,哨兵也會(huì)與slave建立兩條連接執(zhí)行監(jiān)控。通過(guò)INFO命令,哨兵可以獲取主從數(shù)據(jù)庫(kù)的最新信息,并進(jìn)行相應(yīng)的操作,比如角色變更等。
接下來(lái)哨兵向主從數(shù)據(jù)庫(kù)的_sentinel_:hello頻道發(fā)送信息與同樣監(jiān)控這些數(shù)據(jù)庫(kù)的哨兵共享自己的信息,發(fā)送內(nèi)容為哨兵的ip端口、運(yùn)行id、配置版本、master名字、master的ip端口還有master的配置版本。這些信息有以下用處:
- 其他哨兵可以通過(guò)該信息判斷發(fā)送者是否是新發(fā)現(xiàn)的哨兵,如果是的話會(huì)創(chuàng)建一個(gè)到該哨兵的連接用于發(fā)送PING命令。
- 其他哨兵通過(guò)該信息可以判斷master的版本,如果該版本高于直接記錄的版本,將會(huì)更新
- 當(dāng)實(shí)現(xiàn)了自動(dòng)發(fā)現(xiàn)slave和其他哨兵節(jié)點(diǎn)后,哨兵就可以通過(guò)定期發(fā)送PING命令定時(shí)監(jiān)控這些數(shù)據(jù)庫(kù)和節(jié)點(diǎn)有沒(méi)有停止服務(wù)。
如果被PING的數(shù)據(jù)庫(kù)或者節(jié)點(diǎn)超時(shí)(通過(guò) sentinel down-after-milliseconds master-name milliseconds
配置)未回復(fù),哨兵認(rèn)為其主觀下線(sdown,s就是Subjectively —— 主觀地)。如果下線的是master,哨兵會(huì)向其它哨兵發(fā)送命令詢問(wèn)它們是否也認(rèn)為該master主觀下線,如果達(dá)到一定數(shù)目(即配置文件中的quorum)投票,哨兵會(huì)認(rèn)為該master已經(jīng)客觀下線(odown,o就是Objectively —— 客觀地),并選舉領(lǐng)頭的哨兵節(jié)點(diǎn)對(duì)主從系統(tǒng)發(fā)起故障恢復(fù)。若沒(méi)有足夠的sentinel進(jìn)程同意master下線,master的客觀下線狀態(tài)會(huì)被移除,若master重新向sentinel進(jìn)程發(fā)送的PING命令返回有效回復(fù),master的主觀下線狀態(tài)就會(huì)被移除
哨兵認(rèn)為master客觀下線后,故障恢復(fù)的操作需要由選舉的領(lǐng)頭哨兵來(lái)執(zhí)行,選舉采用Raft算法:
- 發(fā)現(xiàn)master下線的哨兵節(jié)點(diǎn)(我們稱他為A)向每個(gè)哨兵發(fā)送命令,要求對(duì)方選自己為領(lǐng)頭哨兵
- 如果目標(biāo)哨兵節(jié)點(diǎn)沒(méi)有選過(guò)其他人,則會(huì)同意選舉A為領(lǐng)頭哨兵
- 如果有超過(guò)一半的哨兵同意選舉A為領(lǐng)頭,則A當(dāng)選
- 如果有多個(gè)哨兵節(jié)點(diǎn)同時(shí)參選領(lǐng)頭,此時(shí)有可能存在一輪投票無(wú)競(jìng)選者勝出,此時(shí)每個(gè)參選的節(jié)點(diǎn)等待一個(gè)隨機(jī)時(shí)間后再次發(fā)起參選請(qǐng)求,進(jìn)行下一輪投票競(jìng)選,直至選舉出領(lǐng)頭哨兵
選出領(lǐng)頭哨兵后,領(lǐng)頭者開(kāi)始對(duì)系統(tǒng)進(jìn)行故障恢復(fù),從出現(xiàn)故障的master的從數(shù)據(jù)庫(kù)中挑選一個(gè)來(lái)當(dāng)選新的master,選擇規(guī)則如下:
- 所有在線的slave中選擇優(yōu)先級(jí)最高的,優(yōu)先級(jí)可以通過(guò)slave-priority配置
- 如果有多個(gè)最高優(yōu)先級(jí)的slave,則選取復(fù)制偏移量最大(即復(fù)制越完整)的當(dāng)選
- 如果以上條件都一樣,選取id最小的slave
挑選出需要繼任的slave后,領(lǐng)頭哨兵向該數(shù)據(jù)庫(kù)發(fā)送命令使其升格為master,然后再向其他slave發(fā)送命令接受新的master,最后更新數(shù)據(jù)。將已經(jīng)停止的舊的master更新為新的master的從數(shù)據(jù)庫(kù),使其恢復(fù)服務(wù)后以slave的身份繼續(xù)運(yùn)行。
2. 部署演示
本示例基于Redis 5.0.3版。
哨兵模式基于前文的主從復(fù)制模式。哨兵的配置文件為sentinel.conf,在文件中添加
sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定義一個(gè)master數(shù)據(jù)庫(kù)的名稱,后面是master的ip, port,1表示至少需要一個(gè)Sentinel進(jìn)程同意才能將master判斷為失效,如果不滿足這個(gè)條件,則自動(dòng)故障轉(zhuǎn)移(failover)不會(huì)執(zhí)行
sentinel auth-pass mymaster 123456 # master的密碼
sentinel down-after-milliseconds mymaster 5000 # 5s未回復(fù)PING,則認(rèn)為master主觀下線,默認(rèn)為30s
sentinel parallel-syncs mymaster 2 # 指定在執(zhí)行故障轉(zhuǎn)移時(shí),最多可以有多少個(gè)slave實(shí)例在同步新的master實(shí)例,在slave實(shí)例較多的情況下這個(gè)數(shù)字越小,同步的時(shí)間越長(zhǎng),完成故障轉(zhuǎn)移所需的時(shí)間就越長(zhǎng)
sentinel failover-timeout mymaster 300000 # 如果在該時(shí)間(ms)內(nèi)未能完成故障轉(zhuǎn)移操作,則認(rèn)為故障轉(zhuǎn)移失敗,生產(chǎn)環(huán)境需要根據(jù)數(shù)據(jù)量設(shè)置該值
一個(gè)哨兵可以監(jiān)控多個(gè)master數(shù)據(jù)庫(kù),只需按上述配置添加多套
分別以26379,36379,46379端口啟動(dòng)三個(gè)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
命令啟動(dòng)。此時(shí)集群包含一個(gè)master、兩個(gè)slave、三個(gè)sentinel,如圖,
我們來(lái)模擬master掛掉的場(chǎng)景,執(zhí)行 kill -9 3017
將master進(jìn)程干掉,進(jìn)入slave中執(zhí)行 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已經(jīng)成功上位晉升為master(role:master),接收一個(gè)slave 7001的連接。此時(shí)查看slave2.conf配置文件,發(fā)現(xiàn)replicaof
的配置已經(jīng)被移除了,slave1.conf的配置文件里replicaof 127.0.0.1 6379
被改為 replicaof 127.0.0.1 7002
。重新啟動(dòng)master,也可以看到master.conf配置文件中添加了replicaof 127.0.0.1 7002
的配置項(xiàng),可見(jiàn)大哥(master)下位后,再出來(lái)混就只能當(dāng)當(dāng)小弟(slave)了,三十年河?xùn)|三十年河西。
3. 哨兵模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn):
- 哨兵模式基于主從復(fù)制模式,所以主從復(fù)制模式有的優(yōu)點(diǎn),哨兵模式也有
- 哨兵模式下,master掛掉可以自動(dòng)進(jìn)行切換,系統(tǒng)可用性更高
缺點(diǎn):
- 同樣也繼承了主從模式難以在線擴(kuò)容的缺點(diǎn),Redis的容量受限于單機(jī)配置
- 需要額外的資源來(lái)啟動(dòng)sentinel進(jìn)程,實(shí)現(xiàn)相對(duì)復(fù)雜一點(diǎn),同時(shí)slave節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)
Cluster模式
1. 基本原理
哨兵模式解決了主從復(fù)制不能自動(dòng)故障轉(zhuǎn)移,達(dá)不到高可用的問(wèn)題,但還是存在難以在線擴(kuò)容,Redis容量受限于單機(jī)配置的問(wèn)題。Cluster模式實(shí)現(xiàn)了Redis的分布式存儲(chǔ),即每臺(tái)節(jié)點(diǎn)存儲(chǔ)不同的內(nèi)容,來(lái)解決在線擴(kuò)容的問(wèn)題。如圖
Cluster采用無(wú)中心結(jié)構(gòu),它的特點(diǎn)如下:
- 所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬
- 節(jié)點(diǎn)的fail是通過(guò)集群中超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效
- 客戶端與redis節(jié)點(diǎn)直連,不需要中間代理層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可
Cluster模式的具體工作機(jī)制:
- 在Redis的每個(gè)節(jié)點(diǎn)上,都有一個(gè)插槽(slot),取值范圍為0-16383
- 當(dāng)我們存取key的時(shí)候,Redis會(huì)根據(jù)CRC16的算法得出一個(gè)結(jié)果,然后把結(jié)果對(duì)16384求余數(shù),這樣每個(gè)key都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在0-16383之間的哈希槽,通過(guò)這個(gè)值,去找到對(duì)應(yīng)的插槽所對(duì)應(yīng)的節(jié)點(diǎn),然后直接自動(dòng)跳轉(zhuǎn)到這個(gè)對(duì)應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作
- 為了保證高可用,Cluster模式也引入主從復(fù)制模式,一個(gè)主節(jié)點(diǎn)對(duì)應(yīng)一個(gè)或者多個(gè)從節(jié)點(diǎn),當(dāng)主節(jié)點(diǎn)宕機(jī)的時(shí)候,就會(huì)啟用從節(jié)點(diǎn)
- 當(dāng)其它主節(jié)點(diǎn)ping一個(gè)主節(jié)點(diǎn)A時(shí),如果半數(shù)以上的主節(jié)點(diǎn)與A通信超時(shí),那么認(rèn)為主節(jié)點(diǎn)A宕機(jī)了。如果主節(jié)點(diǎn)A和它的從節(jié)點(diǎn)都宕機(jī)了,那么該集群就無(wú)法再提供服務(wù)了
Cluster模式集群節(jié)點(diǎn)最小配置6個(gè)節(jié)點(diǎn)(3主3從,因?yàn)樾枰霐?shù)以上),其中主節(jié)點(diǎn)提供讀寫操作,從節(jié)點(diǎn)作為備用節(jié)點(diǎn),不提供請(qǐng)求,只作為故障轉(zhuǎn)移使用。
2. 部署演示
本示例基于Redis 5.0.3版。
Cluster模式的部署比較簡(jiǎn)單,首先在redis.conf中
port 7100 # 本示例6個(gè)節(jié)點(diǎn)端口分別為7100,7200,7300,7400,7500,7600
daemonize yes # r后臺(tái)運(yùn)行
pidfile /var/run/redis_7100.pid # pidfile文件對(duì)應(yīng)7100,7200,7300,7400,7500,7600
cluster-enabled yes # 開(kāi)啟集群模式
masterauth passw0rd # 如果設(shè)置了密碼,需要指定master密碼
cluster-config-file nodes_7100.conf # 集群的配置文件,同樣對(duì)應(yīng)7100,7200等六個(gè)節(jié)點(diǎn)
cluster-node-timeout 15000 # 請(qǐng)求超時(shí) 默認(rèn)15秒,可自行設(shè)置
分別以端口7100,7200,7300,7400,7500,7600 啟動(dòng)六個(gè)實(shí)例(如果是每個(gè)服務(wù)器一個(gè)實(shí)例則配置可一樣)
[root@dev-server-1 cluster]# redis-server redis_7100.conf
[root@dev-server-1 cluster]# redis-server redis_7200.conf
...
然后通過(guò)命令將這個(gè)6個(gè)實(shí)例組成一個(gè)3主節(jié)點(diǎn)3從節(jié)點(diǎn)的集群,
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
執(zhí)行結(jié)果如圖
可以看到 7100, 7200, 7300 作為3個(gè)主節(jié)點(diǎn),分配的slot分別為 0-5460, 5461-10922, 10923-16383, 7600作為7100的slave, 7500作為7300的slave,7400作為7200的slave。
我們連接7100設(shè)置一個(gè)值
[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 參數(shù)表示以集群模式,否則報(bào) (error) MOVED 9421 127.0.0.1:7200
錯(cuò)誤, 以 -a 參數(shù)指定密碼,否則報(bào)(error) NOAUTH Authentication required
錯(cuò)誤。
從上面命令看到key為site算出的slot為9421,落在7200節(jié)點(diǎn)上,所以有Redirected to slot [9421] located at 127.0.0.1:7200
,集群會(huì)自動(dòng)進(jìn)行跳轉(zhuǎn)。因此客戶端可以連接任何一個(gè)節(jié)點(diǎn)來(lái)進(jìn)行數(shù)據(jù)的存取。
通過(guò)cluster nodes
可查看集群的節(jié)點(diǎn)信息
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通過(guò) kill -9 pid
殺死進(jìn)程來(lái)驗(yàn)證集群的高可用,重新進(jìn)入集群執(zhí)行cluster nodes
可以看到7200 fail了,但是7400成了master,重新啟動(dòng)7200,可以看到此時(shí)7200已經(jīng)變成了slave。
3. Cluster模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn):
- 無(wú)中心架構(gòu),數(shù)據(jù)按照slot分布在多個(gè)節(jié)點(diǎn)。
- 集群中的每個(gè)節(jié)點(diǎn)都是平等的關(guān)系,每個(gè)節(jié)點(diǎn)都保存各自的數(shù)據(jù)和整個(gè)集群的狀態(tài)。每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接,而且這些連接保持活躍,這樣就保證了我們只需要連接集群中的任意一個(gè)節(jié)點(diǎn),就可以獲取到其他節(jié)點(diǎn)的數(shù)據(jù)。
- 可線性擴(kuò)展到1000多個(gè)節(jié)點(diǎn),節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除
- 能夠?qū)崿F(xiàn)自動(dòng)故障轉(zhuǎn)移,節(jié)點(diǎn)之間通過(guò)gossip協(xié)議交換狀態(tài)信息,用投票機(jī)制完成slave到master的角色轉(zhuǎn)換
缺點(diǎn):
- 客戶端實(shí)現(xiàn)復(fù)雜,驅(qū)動(dòng)要求實(shí)現(xiàn)Smart Client,緩存slots mapping信息并及時(shí)更新,提高了開(kāi)發(fā)難度。目前僅JedisCluster相對(duì)成熟,異常處理還不完善,比如常見(jiàn)的“max redirect exception”
- 節(jié)點(diǎn)會(huì)因?yàn)槟承┰虬l(fā)生阻塞(阻塞時(shí)間大于 cluster-node-timeout)被判斷下線,這種failover是沒(méi)有必要的
- 數(shù)據(jù)通過(guò)異步復(fù)制,不保證數(shù)據(jù)的強(qiáng)一致性
- slave充當(dāng)“冷備”,不能緩解讀壓力
- 批量操作限制,目前只支持具有相同slot值的key執(zhí)行批量操作,對(duì)mset、mget、sunion等操作支持不友好
- key事務(wù)操作支持有線,只支持多key在同一節(jié)點(diǎn)的事務(wù)操作,多key分布不同節(jié)點(diǎn)時(shí)無(wú)法使用事務(wù)功能
- 不支持多數(shù)據(jù)庫(kù)空間,單機(jī)redis可以支持16個(gè)db,集群模式下只能使用一個(gè),即db 0
Redis Cluster模式不建議使用pipeline和multi-keys操作,減少max redirect產(chǎn)生的場(chǎng)景。
總結(jié)
本文介紹了Redis集群方案的三種模式,其中主從復(fù)制模式能實(shí)現(xiàn)讀寫分離,但是不能自動(dòng)故障轉(zhuǎn)移;哨兵模式基于主從復(fù)制模式,能實(shí)現(xiàn)自動(dòng)故障轉(zhuǎn)移,達(dá)到高可用,但與主從復(fù)制模式一樣,不能在線擴(kuò)容,容量受限于單機(jī)的配置;Cluster模式通過(guò)無(wú)中心化架構(gòu),實(shí)現(xiàn)分布式存儲(chǔ),可進(jìn)行線性擴(kuò)展,也能高可用,但對(duì)于像批量操作、事務(wù)操作等的支持性不夠好。三種模式各有優(yōu)缺點(diǎn),可根據(jù)實(shí)際場(chǎng)景進(jìn)行選擇。
參考:
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
到此這篇關(guān)于一文掌握Redis的三種集群方案(小結(jié))的文章就介紹到這了,更多相關(guān)Redis 集群內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- 詳細(xì)分析Redis集群故障
- Redis集群搭建全記錄
- Redis集群下過(guò)期key監(jiān)聽(tīng)的實(shí)現(xiàn)代碼
- 基于redis集群設(shè)置密碼的實(shí)例
- redis集群搭建教程及遇到的問(wèn)題處理