Redis中實現(xiàn)集群的方法有哪些-創(chuàng)新互聯(lián)

Redis中實現(xiàn)集群的方法有哪些？很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

成都創(chuàng)新互聯(lián)公司服務(wù)項目包括臨夏網(wǎng)站建設(shè)、臨夏網(wǎng)站制作、臨夏網(wǎng)頁制作以及臨夏網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，臨夏網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到臨夏省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

Redis支持三種集群方案

主從復(fù)制模式
Sentinel（哨兵）模式
Cluster模式

主從復(fù)制模式

1. 基本原理

主從復(fù)制模式中包含一個主數(shù)據(jù)庫實例（master）與一個或多個從數(shù)據(jù)庫實例（slave），如下圖

Redis中實現(xiàn)集群的方法有哪些

客戶端可對主數(shù)據(jù)庫進(jìn)行讀寫操作，對從數(shù)據(jù)庫進(jìn)行讀操作，主數(shù)據(jù)庫寫入的數(shù)據(jù)會實時自動同步給從數(shù)據(jù)庫。

具體工作機(jī)制為：

slave啟動后，向master發(fā)送SYNC命令，master接收到SYNC命令后通過bgsave保存快照（即上文所介紹的RDB持久化），并使用緩沖區(qū)記錄保存快照這段時間內(nèi)執(zhí)行的寫命令
master將保存的快照文件發(fā)送給slave，并繼續(xù)記錄執(zhí)行的寫命令
slave接收到快照文件后，加載快照文件，載入數(shù)據(jù)
master快照發(fā)送完后開始向slave發(fā)送緩沖區(qū)的寫命令，slave接收命令并執(zhí)行，完成復(fù)制初始化
此后master每次執(zhí)行一個寫命令都會同步發(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)聽的網(wǎng)卡IP，注釋掉或配置成0.0.0.0可使任意IP均可訪問
protected-mode no # 關(guān)閉保護(hù)模式，使用密碼訪問
port 6379 # 設(shè)置監(jiān)聽端口，建議生產(chǎn)環(huán)境均使用自定義端口
timeout 30 # 客戶端連接空閑多久后斷開連接，單位秒，0表示禁用

###通用配置###
daemonize yes # 在后臺運(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 #是否對RDB文件進(jìn)行壓縮，建議設(shè)置為no，以（磁盤）空間換（CPU）時間
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無法與master同步，設(shè)置成slave不可讀，方便監(jiān)控腳本發(fā)現(xiàn)問題

本示例在單臺服務(wù)器上配置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

進(jìn)入master數(shù)據(jù)庫，寫入一個數(shù)據(jù)，再進(jìn)入一個slave數(shù)據(jù)庫，立即便可訪問剛才寫入master數(shù)據(jù)庫的數(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ù)庫的其它庫的信息，如上可看到有兩個slave連接到master

3. 主從復(fù)制的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

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

缺點(diǎn)：

不具備自動容錯與恢復(fù)功能，master或slave的宕機(jī)都可能導(dǎo)致客戶端請求失敗，需要等待機(jī)器重啟或手動切換客戶端IP才能恢復(fù)
master宕機(jī)，如果宕機(jī)前數(shù)據(jù)沒有同步完，則切換IP后會存在數(shù)據(jù)不一致的問題
難以支持在線擴(kuò)容，Redis的容量受限于單機(jī)配置

Sentinel（哨兵）模式

1. 基本原理

哨兵模式基于主從復(fù)制模式，只是引入了哨兵來監(jiān)控與自動處理故障。如圖

Redis中實現(xiàn)集群的方法有哪些

哨兵顧名思義，就是來為Redis集群站哨的，一旦發(fā)現(xiàn)問題能做出相應(yīng)的應(yīng)對處理。其功能包括

監(jiān)控master、slave是否正常運(yùn)行
當(dāng)master出現(xiàn)故障時，能自動將一個slave轉(zhuǎn)換為master（大哥掛了，選一個小弟上位）
多個哨兵可以監(jiān)控同一個Redis，哨兵之間也會自動監(jiān)控

哨兵模式的具體工作機(jī)制：

在配置文件中通過sentinel monitor <master-name> <ip> <redis-port> <quorum> 來定位master的IP、端口，一個哨兵可以監(jiān)控多個master數(shù)據(jù)庫，只需要提供多個該配置項即可。哨兵啟動后，會與要監(jiān)控的master建立兩條連接：

一條連接用來訂閱master的_sentinel_:hello頻道與獲取其他監(jiān)控該master的哨兵節(jié)點(diǎn)信息
另一條連接定期向master發(fā)送INFO等命令獲取master本身的信息

與master建立連接后，哨兵會執(zhí)行三個操作：

定期（一般10s一次，當(dāng)master被標(biāo)記為主觀下線時，改為1s一次）向master和slave發(fā)送INFO命令
定期向master和slave的_sentinel_:hello頻道發(fā)送自己的信息
定期（1s一次）向master、slave和其他哨兵發(fā)送PING命令

發(fā)送INFO命令可以獲取當(dāng)前數(shù)據(jù)庫的相關(guān)信息從而實現(xiàn)新節(jié)點(diǎn)的自動發(fā)現(xiàn)。所以說哨兵只需要配置master數(shù)據(jù)庫信息就可以自動發(fā)現(xiàn)其slave信息。獲取到slave信息后，哨兵也會與slave建立兩條連接執(zhí)行監(jiān)控。通過INFO命令，哨兵可以獲取主從數(shù)據(jù)庫的新信息，并進(jìn)行相應(yīng)的操作，比如角色變更等。

接下來哨兵向主從數(shù)據(jù)庫的_sentinel_:hello頻道發(fā)送信息與同樣監(jiān)控這些數(shù)據(jù)庫的哨兵共享自己的信息，發(fā)送內(nèi)容為哨兵的ip端口、運(yùn)行id、配置版本、master名字、master的ip端口還有master的配置版本。這些信息有以下用處：

其他哨兵可以通過該信息判斷發(fā)送者是否是新發(fā)現(xiàn)的哨兵，如果是的話會創(chuàng)建一個到該哨兵的連接用于發(fā)送PING命令。
其他哨兵通過該信息可以判斷master的版本，如果該版本高于直接記錄的版本，將會更新
當(dāng)實現(xiàn)了自動發(fā)現(xiàn)slave和其他哨兵節(jié)點(diǎn)后，哨兵就可以通過定期發(fā)送PING命令定時監(jiān)控這些數(shù)據(jù)庫和節(jié)點(diǎn)有沒有停止服務(wù)。

如果被PING的數(shù)據(jù)庫或者節(jié)點(diǎn)超時（通過sentinel down-after-milliseconds master-name milliseconds 配置）未回復(fù)，哨兵認(rèn)為其主觀下線（sdown，s就是Subjectively —— 主觀地）。如果下線的是master，哨兵會向其它哨兵發(fā)送命令詢問它們是否也認(rèn)為該master主觀下線，如果達(dá)到一定數(shù)目（即配置文件中的quorum）投票，哨兵會認(rèn)為該master已經(jīng)客觀下線（odown，o就是Objectively —— 客觀地），并選舉領(lǐng)頭的哨兵節(jié)點(diǎn)對主從系統(tǒng)發(fā)起故障恢復(fù)。若沒有足夠的sentinel進(jìn)程同意master下線，master的客觀下線狀態(tài)會被移除，若master重新向sentinel進(jìn)程發(fā)送的PING命令返回有效回復(fù)，master的主觀下線狀態(tài)就會被移除

哨兵認(rèn)為master客觀下線后，故障恢復(fù)的操作需要由選舉的領(lǐng)頭哨兵來執(zhí)行，選舉采用Raft算法：

發(fā)現(xiàn)master下線的哨兵節(jié)點(diǎn)（我們稱他為A）向每個哨兵發(fā)送命令，要求對方選自己為領(lǐng)頭哨兵
如果目標(biāo)哨兵節(jié)點(diǎn)沒有選過其他人，則會同意選舉A為領(lǐng)頭哨兵
如果有超過一半的哨兵同意選舉A為領(lǐng)頭，則A當(dāng)選
如果有多個哨兵節(jié)點(diǎn)同時參選領(lǐng)頭，此時有可能存在一輪投票無競選者勝出，此時每個參選的節(jié)點(diǎn)等待一個隨機(jī)時間后再次發(fā)起參選請求，進(jìn)行下一輪投票競選，直至選舉出領(lǐng)頭哨兵

選出領(lǐng)頭哨兵后，領(lǐng)頭者開始對系統(tǒng)進(jìn)行故障恢復(fù)，從出現(xiàn)故障的master的從數(shù)據(jù)庫中挑選一個來當(dāng)選新的master,選擇規(guī)則如下：

所有在線的slave中選擇優(yōu)先級高的，優(yōu)先級可以通過slave-priority配置
如果有多個高優(yōu)先級的slave，則選取復(fù)制偏移量較大（即復(fù)制越完整）的當(dāng)選
如果以上條件都一樣，選取id最小的slave

挑選出需要繼任的slave后，領(lǐng)頭哨兵向該數(shù)據(jù)庫發(fā)送命令使其升格為master，然后再向其他slave發(fā)送命令接受新的master，最后更新數(shù)據(jù)。將已經(jīng)停止的舊的master更新為新的master的從數(shù)據(jù)庫，使其恢復(fù)服務(wù)后以slave的身份繼續(xù)運(yùn)行。

2. 部署演示

本示例基于Redis 5.0.3版。

哨兵模式基于前文的主從復(fù)制模式。哨兵的配置文件為sentinel.conf，在文件中添加

sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定義一個master數(shù)據(jù)庫的名稱，后面是master的ip， port，1表示至少需要一個Sentinel進(jìn)程同意才能將master判斷為失效，如果不滿足這個條件，則自動故障轉(zhuǎn)移（failover）不會執(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)移時，最多可以有多少個slave實例在同步新的master實例，在slave實例較多的情況下這個數(shù)字越小，同步的時間越長，完成故障轉(zhuǎn)移所需的時間就越長
sentinel failover-timeout mymaster 300000 # 如果在該時間（ms）內(nèi)未能完成故障轉(zhuǎn)移操作，則認(rèn)為故障轉(zhuǎn)移失敗，生產(chǎn)環(huán)境需要根據(jù)數(shù)據(jù)量設(shè)置該值

一個哨兵可以監(jiān)控多個master數(shù)據(jù)庫，只需按上述配置添加多套

分別以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，如圖，

Redis中實現(xiàn)集群的方法有哪些

我們來模擬master掛掉的場景，執(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），接收一個slave 7001的連接。此時查看slave2.conf配置文件，發(fā)現(xiàn)replicaof的配置已經(jīng)被移除了，slave1.conf的配置文件里replicaof 127.0.0.1 6379 被改為replicaof 127.0.0.1 7002。重新啟動master，也可以看到master.conf配置文件中添加了replicaof 127.0.0.1 7002的配置項，可見大哥（master）下位后，再出來混就只能當(dāng)當(dāng)小弟（slave）了，三十年河?xùn)|三十年河西。

3. 哨兵模式的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

哨兵模式基于主從復(fù)制模式，所以主從復(fù)制模式有的優(yōu)點(diǎn)，哨兵模式也有
哨兵模式下，master掛掉可以自動進(jìn)行切換，系統(tǒng)可用性更高

缺點(diǎn)：

同樣也繼承了主從模式難以在線擴(kuò)容的缺點(diǎn)，Redis的容量受限于單機(jī)配置
需要額外的資源來啟動sentinel進(jìn)程，實現(xiàn)相對復(fù)雜一點(diǎn)，同時slave節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)

Cluster模式

1. 基本原理

哨兵模式解決了主從復(fù)制不能自動故障轉(zhuǎn)移，達(dá)不到高可用的問題，但還是存在難以在線擴(kuò)容，Redis容量受限于單機(jī)配置的問題。Cluster模式實現(xiàn)了Redis的分布式存儲，即每臺節(jié)點(diǎn)存儲不同的內(nèi)容，來解決在線擴(kuò)容的問題。如圖

Redis中實現(xiàn)集群的方法有哪些

Cluster采用無中心結(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是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測失效時才生效
客戶端與redis節(jié)點(diǎn)直連,不需要中間代理層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個可用節(jié)點(diǎn)即可

Cluster模式的具體工作機(jī)制：

在Redis的每個節(jié)點(diǎn)上，都有一個插槽（slot），取值范圍為0-16383
當(dāng)我們存取key的時候，Redis會根據(jù)CRC16的算法得出一個結(jié)果，然后把結(jié)果對16384求余數(shù)，這樣每個key都會對應(yīng)一個編號在0-16383之間的哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點(diǎn)，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作
為了保證高可用，Cluster模式也引入主從復(fù)制模式，一個主節(jié)點(diǎn)對應(yīng)一個或者多個從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)宕機(jī)的時候，就會啟用從節(jié)點(diǎn)
當(dāng)其它主節(jié)點(diǎn)ping一個主節(jié)點(diǎn)A時，如果半數(shù)以上的主節(jié)點(diǎn)與A通信超時，那么認(rèn)為主節(jié)點(diǎn)A宕機(jī)了。如果主節(jié)點(diǎn)A和它的從節(jié)點(diǎn)都宕機(jī)了，那么該集群就無法再提供服務(wù)了

Cluster模式集群節(jié)點(diǎn)最小配置6個節(jié)點(diǎn)(3主3從，因為需要半數(shù)以上)，其中主節(jié)點(diǎn)提供讀寫操作，從節(jié)點(diǎn)作為備用節(jié)點(diǎn)，不提供請求，只作為故障轉(zhuǎn)移使用。

2. 部署演示

本示例基于Redis 5.0.3版。

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

port 7100 # 本示例6個節(jié)點(diǎn)端口分別為7100,7200,7300,7400,7500,7600 
daemonize yes # r后臺運(yùn)行 
pidfile /var/run/redis_7100.pid # pidfile文件對應(yīng)7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 開啟集群模式 
masterauth passw0rd # 如果設(shè)置了密碼，需要指定master密碼
cluster-config-file nodes_7100.conf # 集群的配置文件，同樣對應(yīng)7100,7200等六個節(jié)點(diǎn)
cluster-node-timeout 15000 # 請求超時 默認(rèn)15秒，可自行設(shè)置

分別以端口7100,7200,7300,7400,7500,7600 啟動六個實例(如果是每個服務(wù)器一個實例則配置可一樣)

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

然后通過命令將這個6個實例組成一個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é)果如圖

Redis中實現(xiàn)集群的方法有哪些

可以看到 7100， 7200， 7300 作為3個主節(jié)點(diǎn)，分配的slot分別為 0-5460， 5461-10922， 10923-16383， 7600作為7100的slave， 7500作為7300的slave，7400作為7200的slave。

我們連接7100設(shè)置一個值

[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ù)表示以集群模式，否則報(error) MOVED 9421 127.0.0.1:7200 錯誤，以 -a 參數(shù)指定密碼，否則報(error) NOAUTH Authentication required錯誤。

從上面命令看到key為site算出的slot為9421，落在7200節(jié)點(diǎn)上，所以有Redirected to slot [9421] located at 127.0.0.1:7200，集群會自動進(jìn)行跳轉(zhuǎn)。因此客戶端可以連接任何一個節(jié)點(diǎn)來進(jìn)行數(shù)據(jù)的存取。

通過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通過kill -9 pid殺死進(jìn)程來驗證集群的高可用，重新進(jìn)入集群執(zhí)行cluster nodes可以看到7200 fail了，但是7400成了master，重新啟動7200，可以看到此時7200已經(jīng)變成了slave。

3. Cluster模式的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

無中心架構(gòu)，數(shù)據(jù)按照slot分布在多個節(jié)點(diǎn)。
集群中的每個節(jié)點(diǎn)都是平等的關(guān)系，每個節(jié)點(diǎn)都保存各自的數(shù)據(jù)和整個集群的狀態(tài)。每個節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接，而且這些連接保持活躍，這樣就保證了我們只需要連接集群中的任意一個節(jié)點(diǎn)，就可以獲取到其他節(jié)點(diǎn)的數(shù)據(jù)。
可線性擴(kuò)展到1000多個節(jié)點(diǎn)，節(jié)點(diǎn)可動態(tài)添加或刪除
能夠?qū)崿F(xiàn)自動故障轉(zhuǎn)移，節(jié)點(diǎn)之間通過gossip協(xié)議交換狀態(tài)信息，用投票機(jī)制完成slave到master的角色轉(zhuǎn)換

缺點(diǎn)：

客戶端實現(xiàn)復(fù)雜，驅(qū)動要求實現(xiàn)Smart Client，緩存slots mapping信息并及時更新，提高了開發(fā)難度。目前僅JedisCluster相對成熟，異常處理還不完善，比如常見的“max redirect exception”
節(jié)點(diǎn)會因為某些原因發(fā)生阻塞（阻塞時間大于 cluster-node-timeout）被判斷下線，這種failover是沒有必要的
數(shù)據(jù)通過異步復(fù)制，不保證數(shù)據(jù)的強(qiáng)一致性
slave充當(dāng)“冷備”，不能緩解讀壓力
批量操作限制，目前只支持具有相同slot值的key執(zhí)行批量操作，對mset、mget、sunion等操作支持不友好
key事務(wù)操作支持有線，只支持多key在同一節(jié)點(diǎn)的事務(wù)操作，多key分布不同節(jié)點(diǎn)時無法使用事務(wù)功能
不支持多數(shù)據(jù)庫空間，單機(jī)redis可以支持16個db，集群模式下只能使用一個，即db 0

Redis Cluster模式不建議使用pipeline和multi-keys操作，減少max redirect產(chǎn)生的場景。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司，的支持。

網(wǎng)頁題目：Redis中實現(xiàn)集群的方法有哪些-創(chuàng)新互聯(lián)
分享路徑：http://bm7419.com/article26/cescjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、網(wǎng)站排名、外貿(mào)網(wǎng)站建設(shè)、ChatGPT、網(wǎng)站制作、App設(shè)計

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容