?1 哨兵模式

????????由于無(wú)法進(jìn)行主動(dòng)恢復(fù)，因此主從模式衍生出了哨兵模式。哨兵模式基于主從復(fù)制模式，只是引入了哨兵來(lái)監(jiān)控與自動(dòng)處理故障。Redis Sentinel是社區(qū)版本推出的原生高可用解決方案，Redis Sentinel部署架構(gòu)主要包括兩部分：Redis Sentinel集群和Redis數(shù)據(jù)集群，其中Redis Sentinel集群是由若干Sentinel節(jié)點(diǎn)組成的分布式集群，可以實(shí)現(xiàn)故障發(fā)現(xiàn)、故障自動(dòng)轉(zhuǎn)移、配置中心和客戶端通知。Redis Sentinel的節(jié)點(diǎn)數(shù)量要滿足2n+1（n>=1）的奇數(shù)個(gè)。

1.1 優(yōu)劣勢(shì)分析

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

1. Redis Sentinel集群部署簡(jiǎn)單
2. 能夠解決Redis主從模式下的高可用切換問(wèn)題
3. 很方便實(shí)現(xiàn)Redis數(shù)據(jù)節(jié)點(diǎn)的線形擴(kuò)展，輕松突破Redis自身單線程瓶頸，可極大滿足對(duì)Redis大容量或高性能的業(yè)務(wù)需求。
4. 可以實(shí)現(xiàn)一套Sentinel監(jiān)控一組Redis數(shù)據(jù)節(jié)點(diǎn)或多組數(shù)據(jù)節(jié)點(diǎn)

1.1.2 缺點(diǎn)

1. 部署相對(duì)Redis 主從模式要復(fù)雜一些，原理理解更繁瑣
2. 資源浪費(fèi)，Redis數(shù)據(jù)節(jié)點(diǎn)中slave節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)
3. Redis Sentinel主要是針對(duì)Redis數(shù)據(jù)節(jié)點(diǎn)中的主節(jié)點(diǎn)的高可用切換，對(duì)Redis的數(shù)據(jù)節(jié)點(diǎn)做失敗判定分為主觀下線和客觀下線兩種，對(duì)于Redis的從節(jié)點(diǎn)有對(duì)節(jié)點(diǎn)做主觀下線操作，并不執(zhí)行故障轉(zhuǎn)移。
4. 不能解決讀寫(xiě)分離問(wèn)題，實(shí)現(xiàn)起來(lái)相對(duì)復(fù)雜

1.2 Sentinel 的三大作用

• 監(jiān)控（Monitoring）： Sentinel 會(huì)不斷地檢查(ping指令)你的主服務(wù)器和從服務(wù)器是否運(yùn)作正常。
• 提醒（Notification）： 當(dāng)個(gè) Sentinel 監(jiān)控 Redis服務(wù)器的狀態(tài)，會(huì)在多個(gè)Sentinel之間進(jìn)行數(shù)據(jù)共享
• 自動(dòng)故障遷移（Automatic failover）： 當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)，Sentinel會(huì)開(kāi)始一次自動(dòng)故障轉(zhuǎn)移操作， 它會(huì)將失效主服務(wù)器的其中一個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器， 并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器。

????????故障轉(zhuǎn)移挑選新master的原則：

1. 在線的slave節(jié)點(diǎn)
2. 響應(yīng)快的（與Sentinel響應(yīng)）
3. 與原master響應(yīng)頻繁的
4. 優(yōu)先原則（offset小的，runid 小的）

????????挑選好新的master節(jié)點(diǎn)后，Sentinel 向 新master發(fā)送 slaveof no one 指令，向其他的slave發(fā)送

slaveof [新master的IP] [新master的端口]

2 Sentinel 模式工作原理

2.1 Redis sentinel工作原理

????????在哨兵模式架構(gòu)中，client端在首次訪問(wèn)Redis服務(wù)時(shí)，實(shí)際上訪問(wèn)的是哨兵（sentinel），sentinel會(huì)將自己監(jiān)控的Redis實(shí)例的master節(jié)點(diǎn)信息返回給client端，client后續(xù)就會(huì)直接訪問(wèn)Redis的master節(jié)點(diǎn)，并不是每次都從哨兵處獲取master節(jié)點(diǎn)的信息。

????????sentinel會(huì)實(shí)時(shí)監(jiān)控所有的Redis實(shí)例是否可用，當(dāng)監(jiān)控到Redis的master節(jié)點(diǎn)發(fā)生故障后，會(huì)從剩余的slave節(jié)點(diǎn)中選舉出一個(gè)作為新的master節(jié)點(diǎn)提供服務(wù)，并將新master節(jié)點(diǎn)的地址通知給client端，其他的slave節(jié)點(diǎn)會(huì)通過(guò)slaveof命令重新掛載到新的master節(jié)點(diǎn)下。當(dāng)原來(lái)的master節(jié)點(diǎn)恢復(fù)后，也會(huì)作為slave節(jié)點(diǎn)掛在新的master節(jié)點(diǎn)下。如下圖：

?????????一般情況下，為了保證高可用，sentinel也會(huì)進(jìn)行集群部署，防止單節(jié)點(diǎn)sentinel掛掉。當(dāng)sentinel集群部署時(shí)，各sentinel除了監(jiān)控redis實(shí)例外，還會(huì)彼此進(jìn)行監(jiān)控。如下圖：

?2.2 Redis sentinel是如何進(jìn)行監(jiān)控的

????????要實(shí)現(xiàn)Redis節(jié)點(diǎn)的監(jiān)控，sentinel首先要得到所有的Redis節(jié)點(diǎn)的信息。sentinel通過(guò)在配置文件中配置 sentinel monitor 選項(xiàng)來(lái)指定要監(jiān)控的redis master節(jié)點(diǎn)的地址，然后在啟動(dòng)sentinel時(shí)，會(huì)創(chuàng)建與redis master節(jié)點(diǎn)的連接并向master節(jié)點(diǎn)發(fā)送一個(gè)info命令，master節(jié)點(diǎn)在收到info命令后，會(huì)將自身節(jié)點(diǎn)的信息和自己下面所有的slave節(jié)點(diǎn)的信息返回給sentinel，sentinel收到反饋后，會(huì)與新的slave節(jié)點(diǎn)創(chuàng)建連接，接下來(lái)就會(huì)每隔10秒鐘向所有的redis節(jié)點(diǎn)發(fā)送info命令來(lái)獲取最新的redis主從結(jié)構(gòu)信息。

????????有了redis實(shí)例的主從信息后，sentinel就會(huì)以每秒鐘一次的頻率向所有redis實(shí)例發(fā)送一個(gè)PING命令，而且如果sentinel是集群部署的話，每個(gè)sentinel還會(huì)以同樣的頻率向其他sentinel實(shí)例發(fā)送PING命令。當(dāng)redis實(shí)例和sentinel實(shí)例收到PING命令后，會(huì)向sentinel返回一個(gè)有效的回復(fù)：+PONG 、-LOADING 或者 -MASTERDOWN，若返回其他的回復(fù)，或者在指定時(shí)間內(nèi)（sentinel down-after-milliseconds 選項(xiàng)配置）沒(méi)有回復(fù)，那么sentinel認(rèn)為實(shí)例的回復(fù)無(wú)效。如果實(shí)例在 sentinel down-after-milliseconds 時(shí)間內(nèi)未返回過(guò)一次有效的回復(fù)，那該實(shí)例就會(huì)被sentinel標(biāo)記為主觀下線（Subjectively Down，簡(jiǎn)稱 SDOWN，指的是單個(gè) sentinel 實(shí)例對(duì)服務(wù)節(jié)點(diǎn)做出的下線判斷）。

????????當(dāng)redis master節(jié)點(diǎn)被足夠數(shù)量（sentinel monitor 選項(xiàng)配置，其中的quorum即為指定的sentinel數(shù)量，下面會(huì)詳細(xì)介紹相關(guān)參數(shù)）的sentinel標(biāo)記為主觀下線后，那么master節(jié)點(diǎn)就會(huì)被標(biāo)記為客觀下線（Objectively Down，簡(jiǎn)稱 ODOWN，指的是多個(gè) sentinel 實(shí)例在對(duì)同一個(gè)服務(wù)器做出 SDOWN 判斷， 并且通過(guò) SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務(wù)器下線判斷?！疽粋€(gè) sentinel 可以通過(guò)向另一個(gè) sentinel 發(fā)送 SENTINEL is-master-down-by-addr 命令來(lái)詢問(wèn)對(duì)方是否認(rèn)為給定的服務(wù)器已下線】）。客觀下線條件只適用于主服務(wù)器： 對(duì)于任何其他類型的 Redis 實(shí)例，sentinel 在將它們判斷為下線前不需要進(jìn)行協(xié)商， 所以slave服務(wù)器或者其他 sentinel 永遠(yuǎn)不會(huì)達(dá)到客觀下線條件。

????????當(dāng)redis master被標(biāo)記為客觀下線時(shí)，每個(gè)sentinel向其他slave節(jié)點(diǎn)發(fā)送info命令的頻率由之前的10秒鐘一次變?yōu)?秒鐘一次。并且會(huì)通過(guò)raft算法在sentinel中選出一個(gè)leader，由leader節(jié)點(diǎn)完成redis的故障轉(zhuǎn)移工作。

2.2.1 主動(dòng)下線

????????概念：主觀下線（Subjectively Down， 簡(jiǎn)稱 SDOWN）指的是單個(gè) Sentinel 實(shí)例對(duì)服務(wù)器做出的下線判斷。

????????如果一個(gè) redis 服務(wù)器沒(méi)有在 master-down-after-milliseconds 選項(xiàng)所指定的時(shí)間內(nèi)，對(duì)向它發(fā)送 PING 命令的 Sentinel 返回一個(gè)有效回復(fù)， 那么Sentinel 就會(huì)將這個(gè)服務(wù)器標(biāo)記為主觀下線。

????????單個(gè)Sentine判斷Redis服務(wù)器主觀下線之后，會(huì)通過(guò)提醒（流言傳播（Gossip））告知其他的Sentinel服務(wù)器，其他的Sentinel就來(lái)圍觀這臺(tái)Redis服務(wù)器，超過(guò)半數(shù)的Sentinel認(rèn)為Redis主管下線后，則該Redis服務(wù)器的狀態(tài)變?yōu)榭陀^下線。

2.2.2 客觀下線

????????概念：多個(gè) Sentinel 實(shí)例在對(duì)同一個(gè)服務(wù)器做出 SDOWN 判斷， 并且通過(guò)SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務(wù)器下線判斷ODOWN。 （一個(gè)Sentinel 可以通過(guò)向另一個(gè) Sentinel 發(fā)送命令來(lái)詢問(wèn)對(duì)方是否認(rèn)為給定的服務(wù)器已下線）。

????????客觀下線條件只適用于主服務(wù)器，對(duì)于其他類型的 Redis 實(shí)例， Sentinel在將它們判斷為下線前不不需要進(jìn)行協(xié)商， 所以從服務(wù)器或者其他Sentinel 不會(huì)達(dá)到客觀下線條件。 只要一個(gè) Sentinel 發(fā)現(xiàn)某個(gè)主服務(wù)器進(jìn)入了客觀下線狀態(tài)， 這個(gè)Sentinel就可能會(huì)被其他 Sentinel 推選出，并對(duì)失效的主服務(wù)器執(zhí)行自動(dòng)故障遷移操作。

2.3 Redis sentinel配置

????????在redis安裝目錄下，除了有redis本身的一個(gè)配置文件外，還有一個(gè)sentinel.conf，該文件就是sentinel的配置文件。在該文件中，主要有以下幾個(gè)配置：

• port：sentinel的端口，默認(rèn)為26379；
• daemonize：是否后臺(tái)啟動(dòng)，yes表示以后臺(tái)方式啟動(dòng)運(yùn)行sentinel，默認(rèn)為no；
• logfile：sentinel日志文件存放路徑；
• sentinel monitor ：sentinel監(jiān)控的master節(jié)點(diǎn)的名稱、地址和端口號(hào)，最后一個(gè)quorums表示至少需要多少個(gè)sentinel判定master節(jié)點(diǎn)故障才進(jìn)行故障轉(zhuǎn)移。一般配置為sentinel數(shù)量/2+1。
• sentinel down-after-milliseconds ：sentinel向其他實(shí)例發(fā)送PING命令后到獲得響應(yīng)的超時(shí)時(shí)間，單位為毫秒；
• sentinel failover-timeout ：sentinel在對(duì)master進(jìn)行故障轉(zhuǎn)移時(shí)的超時(shí)時(shí)間，單位毫秒；
• sentinel parallel-syncs ：在執(zhí)行故障轉(zhuǎn)移時(shí)， 最多可以有多少個(gè)從服務(wù)器同時(shí)對(duì)新的主服務(wù)器進(jìn)行同步，這個(gè)數(shù)字越小，完成故障轉(zhuǎn)移所需的時(shí)間就越長(zhǎng)；
• sentinel auth-pass ：如果master節(jié)點(diǎn)設(shè)置了密碼，則需要在這里配置master節(jié)點(diǎn)的密碼，否則sentinel無(wú)法連接master進(jìn)行監(jiān)控。

2.4 Master故障恢復(fù)

????????哨兵認(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)行。

3 Sentinel部署使用

3.1 哨兵部署

3.1.1 sentinel.conf文件配置

　　哨兵模式基于前面的主從復(fù)制模式。哨兵的配置文件為Redis安裝目錄下的sentinel.conf文件，在文件中配置如下配置文件：

port 26379      # 哨兵端口

# mymaster定義一個(gè)master數(shù)據(jù)庫(kù)的名稱，后面是master的ip， port，1表示至少需要一個(gè)Sentinel進(jìn)程同意才能將master判斷為失效，如果不滿足這個(gè)條件，則自動(dòng)故障轉(zhuǎn)移（failover）不會(huì)執(zhí)行
sentinel monitor mymaster 127.0.0.1 6379 1 
sentinel auth-pass mymaster 123456      # master的密碼

sentinel down-after-milliseconds mymaster 5000      #5s未回復(fù)PING，則認(rèn)為master主觀下線，默認(rèn)為30s
# 指定在執(zhí)行故障轉(zhuǎn)移時(shí)，最多可以有多少個(gè)slave實(shí)例在同步新的master實(shí)例，在slave實(shí)例較多的情況下這個(gè)數(shù)字越小，同步的時(shí)間越長(zhǎng)，完成故障轉(zhuǎn)移所需的時(shí)間就越長(zhǎng)
sentinel parallel-syncs mymaster 2  
# 如果在該時(shí)間（ms）內(nèi)未能完成故障轉(zhuǎn)移操作，則認(rèn)為故障轉(zhuǎn)移失敗，生產(chǎn)環(huán)境需要根據(jù)數(shù)據(jù)量設(shè)置該值
sentinel failover-timeout mymaster 300000 

daemonize yes   #用來(lái)指定redis是否要用守護(hù)線程的方式啟動(dòng),默認(rèn)為no
#保護(hù)模式如果開(kāi)啟只接受回環(huán)地址的ipv4和ipv6地址鏈接，拒絕外部鏈接，而且正常應(yīng)該配置多個(gè)哨兵，避免一個(gè)哨兵出現(xiàn)獨(dú)裁情況
#如果配置多個(gè)哨兵那如果開(kāi)啟也會(huì)拒絕其他sentinel的連接。導(dǎo)致哨兵配置無(wú)法生效
protected-mode no 　　
logfile "/data/redis/logs/sentinel.log"  　　  #指明日志文件

　　其中daemonize的值yes和no的區(qū)別為：

• yes: redis采用的是單進(jìn)程多線程的模式。當(dāng)redis.conf中選項(xiàng)daemonize設(shè)置成yes時(shí)，代表開(kāi)啟守護(hù)進(jìn)程模式。在該模式下，redis會(huì)在后臺(tái)運(yùn)行，并將進(jìn)程pid號(hào)寫(xiě)入至redis.conf選項(xiàng)pidfile設(shè)置的文件中，此時(shí)redis將一直運(yùn)行，除非手動(dòng)kill該進(jìn)程。
• no: 當(dāng)daemonize選項(xiàng)設(shè)置成no時(shí)，當(dāng)前界面將進(jìn)入redis的命令行界面，exit強(qiáng)制退出或者關(guān)閉連接工具(putty,xshell等)都會(huì)導(dǎo)致redis進(jìn)程退出。

3.1.2 啟動(dòng)哨兵

　然后就是啟動(dòng)哨兵，啟動(dòng)方式有兩種，先進(jìn)入Redis安裝根目錄下的bin目錄，然后執(zhí)行：

/server-sentinel ../sentinel.conf &
# 或者
redis-server sentinel.conf --sentinel

　　執(zhí)行后可以看到有哨兵進(jìn)程已啟動(dòng)，如下：

192:bin houjing$ ps -ef |grep redis
  501 41115     1   0 11:37下午 ??         0:12.00 ./redis-server 127.0.0.1:6379 
  501 41121     1   0 11:38下午 ??         0:11.88 ./redis-server 127.0.0.1:6380    
  501 41621     1   0  3:53上午 ??         0:00.04 ./redis-server *:26379 [sentinel]

　　可以多個(gè)哨兵監(jiān)控一個(gè)master數(shù)據(jù)庫(kù)，只需按上述配置添加多套sentinel.conf配置文件，比如分別為sentinel1.conf、sentinel2.conf、sentinel3.conf，分別以26379,36379,46379端口啟動(dòng)三個(gè)sentinel，此時(shí)就成功配置多個(gè)哨兵，成功部署了一套3個(gè)哨兵、一個(gè)master、2個(gè)slave的Redis集群。

3.1.3 master節(jié)點(diǎn)宕機(jī)測(cè)試

　　我們通過(guò)手動(dòng)殺掉master節(jié)點(diǎn)進(jìn)行測(cè)試，然后看slave節(jié)點(diǎn)是否會(huì)自動(dòng)晉升為master節(jié)點(diǎn)：

192:bin houjing$ kill -9 41115
192:bin houjing$ ps -ef |grep redis
  501 41121     1   0 11:38下午 ??         0:12.33 ./redis-server 127.0.0.1:6380    
  501 41621     1   0  3:53上午 ??         0:00.68 ./redis-server *:26379 [sentinel]  

127.0.0.1:6379> info replication
Could not connect to Redis at 127.0.0.1:6379: Connection refused

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:14604
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:85362a9182cf9a48d1f93b0633e1963b583c30f7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14604
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14604
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_replid:36bf84c3cb3f2b7969040fdcce9a962025be3605
master_replid2:85362a9182cf9a48d1f93b0633e1963b583c30f7
master_repl_offset:16916
second_repl_offset:15963
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:16916

　　可以看到驗(yàn)證成功，然后我們重啟原先宕機(jī)的master節(jié)點(diǎn)，可以看到原先的節(jié)點(diǎn)成功啟動(dòng)，并由master變成了slave節(jié)點(diǎn)，如下所示：

-cli -p 6380
192:bin houjing$ ./redis-server ../redis.conf &
[1] 41640
192:bin houjing$ 41640:C 07 Apr 2020 03:59:05.475 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
41640:C 07 Apr 2020 03:59:05.475 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=41640, just started
41640:C 07 Apr 2020 03:59:05.475 # Configuration loaded

[1]+  Done                    ./redis-server ../redis.conf
192:bin houjing$ ps -ef |grep redis
  501 41121     1   0 11:38下午 ??         0:12.82 ./redis-server 127.0.0.1:6380    
  501 41621     1   0  3:53上午 ??         0:01.49 ./redis-server *:26379 [sentinel]  
  501 41641     1   0  3:59上午 ??         0:00.02 ./redis-server 127.0.0.1:6379 

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:29056
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:36bf84c3cb3f2b7969040fdcce9a962025be3605
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:29056
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:28488
repl_backlog_histlen:569

　　以上就完成了對(duì)哨兵部署方式的測(cè)試。

?

?參考鏈接

運(yùn)維：終于不用再背著數(shù)萬(wàn)實(shí)例的Redis集群了！_Cluster

Redis學(xué)習(xí)之4種模式實(shí)踐及機(jī)制解析(單機(jī)、主從、哨兵、集群)

redis架構(gòu)_劍八-的博客-CSDN博客

Redis高可用方案—主從（masterslave）架構(gòu)

Redis高可用架構(gòu)—哨兵（sentinel）機(jī)制詳細(xì)介紹

Redis高可用架構(gòu)—Redis集群（Redis Cluster）詳細(xì)介紹

Redis學(xué)習(xí)之Redis集群模式缺陷及其處理文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-457898.html

• Redis學(xué)習(xí)之4種模式實(shí)踐及機(jī)制解析(單機(jī)、主從、哨兵、集群)
• Redis學(xué)習(xí)之API學(xué)習(xí)及Jedis源碼原理分析
• Redis學(xué)習(xí)之Jedis源碼原理分析探究(BIO手寫(xiě)Jedis客戶端)

到了這里，關(guān)于【云原生進(jìn)階之PaaS中間件】第一章Redis-2.3.2哨兵模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！