redis中主從復(fù)制、哨兵、集群的原理是什么

這篇文章主要介紹了redis中主從復(fù)制、哨兵、集群的原理是什么的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇redis中主從復(fù)制、哨兵、集群的原理是什么文章都會(huì)有所收獲，下面我們一起來(lái)看看吧。

一、主從復(fù)制

1. 主從同步的用處

??通過(guò)持久化功能，redis 保證了即使在服務(wù)器重啟的情況下也不會(huì)丟失數(shù)據(jù)，因?yàn)槌志没瘯?huì)把內(nèi)存中的數(shù)據(jù)保存到硬盤(pán)上，重啟會(huì)從硬盤(pán)上加載數(shù)據(jù)，但是由于數(shù)據(jù)是存儲(chǔ)在一臺(tái)服務(wù)器上的，如果這臺(tái)服務(wù)器出現(xiàn)硬盤(pán)故障等問(wèn)題，也會(huì)導(dǎo)致數(shù)據(jù)丟失。為了避免單點(diǎn)故障，通常的做法是將數(shù)據(jù)庫(kù)復(fù)制多個(gè)副本以部署在不同的服務(wù)器上，這樣即使有一臺(tái)服務(wù)器出現(xiàn)故障，其他服務(wù)器依然可以繼續(xù)提供服務(wù)。為此，redis 提供了復(fù)制 replication 功能，可以實(shí)現(xiàn)當(dāng)一臺(tái)數(shù)據(jù)庫(kù)中的數(shù)據(jù)更新后，自動(dòng)將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫(kù)上。

??在復(fù)制的概念中，數(shù)據(jù)庫(kù)分為兩類，一類是主數(shù)據(jù)庫(kù) master，另一類是從數(shù)據(jù)庫(kù) slave。主數(shù)據(jù)庫(kù)可以進(jìn)行讀寫(xiě)操作，當(dāng)寫(xiě)操做導(dǎo)致數(shù)據(jù)變化時(shí)自動(dòng)將數(shù)據(jù)同步給從數(shù)據(jù)庫(kù)，而從數(shù)據(jù)庫(kù)一般是只讀的，并接收主數(shù)據(jù)庫(kù)同步過(guò)來(lái)的數(shù)據(jù)。一個(gè)主數(shù)據(jù)庫(kù)可以擁有多個(gè)從數(shù)據(jù)庫(kù)，而一個(gè)從數(shù)據(jù)庫(kù)只能擁有一個(gè)主數(shù)據(jù)庫(kù)。

2. 主從同步原理

2.1 原理詳解

• 若啟動(dòng)一個(gè) Slave 機(jī)器進(jìn)程，則它會(huì)向 Master 機(jī)器發(fā)送一個(gè) sync_command 命令，請(qǐng)求同步連接。

• 無(wú)論是第一次連接還是重新連接，Master 機(jī)器都會(huì)啟動(dòng)一個(gè)后臺(tái)進(jìn)程，將數(shù)據(jù)快照（RDB）保存到數(shù)據(jù)文件中（.rdb文件），同時(shí) Master 還會(huì)記錄修改數(shù)據(jù)的所有命令并緩存在數(shù)據(jù)文件中。

• 后臺(tái)進(jìn)程完成緩存操作之后，Master 機(jī)器就會(huì)向 Slave 機(jī)器發(fā)送數(shù)據(jù)文件，Slave 端機(jī)器將數(shù)據(jù)文件保存到硬盤(pán)上，然后將其加載到內(nèi)存中，接著 Master 機(jī)器就會(huì)將修改數(shù)據(jù)的所有操作一并發(fā)送給 Slave 端機(jī)器。若 Slave 出現(xiàn)故障導(dǎo)致宕機(jī)，則恢復(fù)正常后會(huì)自動(dòng)重新連接。

• Master 機(jī)器收到 Slave 端機(jī)器的連接后，將其完整的數(shù)據(jù)文件發(fā)送給 Slave 端機(jī)器，如果 Master 同時(shí)收到多個(gè) Slave發(fā)來(lái)的同步請(qǐng)求則 Master 會(huì)在后臺(tái)啟動(dòng)一個(gè)進(jìn)程以保存數(shù)據(jù)文件，然后將其發(fā)送給所有的 Slave 端機(jī)器，確保所有的 Slave 端機(jī)器都正常。

RDB 做全量同步，AOF 做增量同步

2.2 理論精簡(jiǎn)

slave -> master 發(fā)送 sync command 申請(qǐng)同步
master 主進(jìn)程 -> 調(diào)用 fork() 函數(shù) 派生 RDB 子進(jìn)程進(jìn)行持久化 -> 生成 RDB 文件
將 RDB 文件推送給 slaves（完成全量同步）
#增量同步：使用到了 AOF 持久化（機(jī)制：將緩存數(shù)據(jù)保存到緩沖中），所以主從節(jié)點(diǎn)均需要開(kāi)啟 AOF
增量同步是通過(guò) AOF 功能將緩存中的數(shù)據(jù) append（追加）到緩沖中來(lái)進(jìn)行 master 緩沖 -> slave 緩沖的同步
在持續(xù)性的運(yùn)行過(guò)程中，也是增量持續(xù)同步的過(guò)程

2.3 最終精簡(jiǎn)版

slave -> master 發(fā)送 sync
master 使用 RDB 生成 .rdb 文件（全量同步）發(fā)送給 slaves
master 使用 AOF 將緩沖區(qū)數(shù)據(jù)同步給 slaves 緩沖區(qū)數(shù)據(jù)（增量）

二、哨兵模式

1. 哨兵的作用

哨兵的出現(xiàn)主要是解決了主從復(fù)制出現(xiàn)故障時(shí)需要人為干預(yù)的問(wèn)題

哨兵模式主要功能：

集群監(jiān)控：負(fù)責(zé)監(jiān)控 redismaster 和 slave 進(jìn)程是否正常工作
消息通知：如果某個(gè) redis 實(shí)例有故障，那么哨兵負(fù)責(zé)發(fā)送消息作為報(bào)警通知給管理員
故障轉(zhuǎn)移：如果 master node 掛掉了，會(huì)自動(dòng)轉(zhuǎn)移到 slave node 上
配置中心：如果故障轉(zhuǎn)移發(fā)生了，通知 client 客戶端新的 master 地址

??使用一個(gè)或者多個(gè)哨兵 sentinel 實(shí)例組成的系統(tǒng)，對(duì) redis 節(jié)點(diǎn)進(jìn)行監(jiān)控，在主節(jié)點(diǎn)出現(xiàn)故障的情況下，能將從節(jié)點(diǎn)中的一個(gè)升級(jí)為主節(jié)點(diǎn)，進(jìn)行故障轉(zhuǎn)移，保證系統(tǒng)的可用性。

2. 哨兵原理

2.1 原理詳解

• 首先主節(jié)點(diǎn)的信息是配置在哨兵 sentinel 的配置文件中。

• 哨兵節(jié)點(diǎn)會(huì)和配置的主節(jié)點(diǎn)建立起兩條連接命令連接和訂閱連接
  PS：redis 發(fā)布訂閱（pub/sub）是一種消息通信模式:發(fā)送者（pub）發(fā)送消 息，訂閱者 （sub）接收消息。

• 哨兵會(huì)通過(guò)命令連接每 10s 發(fā)送一次 INFO 命令，通過(guò) INFO 命令，主節(jié)點(diǎn)會(huì)返回自己的 run_id 和自己的從節(jié)點(diǎn)信息。

• 哨兵會(huì)對(duì)這些從節(jié)點(diǎn)也建立兩條連接命令連接和訂閱連接。

• 哨兵通過(guò)命令連接向從節(jié)點(diǎn)發(fā)送 INFO 命令，獲取到他的一些信息：

run id（redis 服務(wù)器 id） 
role（職能）
從服務(wù)器的復(fù)制偏移量 offset
其他

• 通過(guò)命令連接向服務(wù)器的 sentinel:hello 頻道發(fā)送一條消息，內(nèi)容包括自己的 IP、端口、run id、配置（后續(xù)投票的時(shí)候會(huì)用到）等。

• 通過(guò)訂閱連接對(duì)服務(wù)器的 sentinel:hello 頻道做了監(jiān)聽(tīng)，所有向該頻道發(fā)送的哨兵的消息都能被接受到。

• 解析監(jiān)聽(tīng)到的消息，進(jìn)行分析提取，就可以知道還有那些別的哨兵服務(wù)節(jié)點(diǎn)也在監(jiān)聽(tīng)這些主從節(jié)點(diǎn)了，更新結(jié)構(gòu)體將這些哨兵節(jié)點(diǎn)記錄下來(lái)。

• 向觀察到的其他的哨兵節(jié)點(diǎn)建立命令連接（此時(shí)沒(méi)有訂閱連接）。

2.2 原理精簡(jiǎn)

3 個(gè)哨兵 3 個(gè) redis

• 三個(gè)哨兵之間建立命令連接，周期檢測(cè) “隊(duì)友” 狀態(tài)

• 哨兵會(huì)向 master 節(jié)點(diǎn)（己在配置文件中指定）發(fā)送兩條連接，分別是命令連接和訂閱連接（為了周期性獲取 master 節(jié)點(diǎn)的數(shù)據(jù))

• 哨兵向 master 周期性發(fā)送 info 命令，master（活著的情況下）會(huì)返回 redis-cli info replication master 節(jié)點(diǎn)的信息 + 從節(jié)點(diǎn)位置

• 哨兵通過(guò) master 返回的信息，再向 slaves 節(jié)點(diǎn)發(fā)送 info 命令，slaves 返回?cái)?shù)據(jù)，從而哨兵集群就可以獲取到 redis 所有集群信息

• 哨兵會(huì)向服務(wù)器發(fā)送命令連接，建立自己的 hello 頻道，哨兵會(huì)向這個(gè) hello 頻道建立訂閱，用于哨兵之間的消息共享

2.3 思路

• 3 個(gè)哨兵互相監(jiān)聽(tīng)，使用 ping 互相檢測(cè)存活

• 3 個(gè)哨兵分別向數(shù)據(jù)節(jié)點(diǎn) master 發(fā)送命令連接和訂閱連接（info 命令）獲取數(shù)據(jù)節(jié)點(diǎn)信息（包含主從節(jié)點(diǎn)）3 個(gè)哨兵再向其他從節(jié)點(diǎn)發(fā)送 info ，用于獲取從節(jié)點(diǎn)詳細(xì)信息

• 3 個(gè)哨兵之間通過(guò) hello 頻道進(jìn)行消息共享

3. 哨兵模式下的故障遷移

• ① 主觀下線
  哨兵節(jié)點(diǎn)會(huì)每秒一次的頻率向建立了命令連接的實(shí)例發(fā)送 PING 命令，如果在 down-after-milliseconds 毫秒內(nèi)沒(méi)有做出有效響應(yīng)包括 PONG/LOADING/MASTERDOWN 以外的響應(yīng)，哨兵就會(huì)將該實(shí)例在本結(jié)構(gòu)體中的狀態(tài)標(biāo)記為 SRI_S_DOWN 主觀下線。

• ② 客觀下線
  當(dāng)一個(gè)哨兵節(jié)點(diǎn)發(fā)現(xiàn)主節(jié)點(diǎn)處于主觀下線狀態(tài)是，會(huì)向其他的哨兵節(jié)點(diǎn)發(fā)出詢問(wèn)，該節(jié)點(diǎn)是不是已經(jīng)主觀下線了。如果超過(guò)配置參數(shù) quorum 個(gè)節(jié)點(diǎn)認(rèn)為是主觀下線時(shí)，該哨兵節(jié)點(diǎn)就會(huì)將自己維護(hù)的結(jié)構(gòu)體中該主節(jié)點(diǎn)標(biāo)記為 SRIO DOWN 客觀下線詢問(wèn)命令 SENTINEL is-master-down-by-addr。

• ③ master 選舉
  在認(rèn)為主節(jié)點(diǎn)客觀下線的情況下，哨兵節(jié)點(diǎn)節(jié)點(diǎn)間會(huì)發(fā)起一次選舉，命令為 SENTINEL is-master-down-by-addr ，只是 runid 這次會(huì)將自己的 runid 帶進(jìn)去，希望接受者將自己設(shè)置為主節(jié)點(diǎn)。如果超過(guò)半數(shù)以上的節(jié)點(diǎn)返回將該節(jié)點(diǎn)標(biāo)記為 leader 的情況下，會(huì)有該 leader 對(duì)故障進(jìn)行遷移。

• ④ 故障轉(zhuǎn)移

####在從節(jié)點(diǎn)中挑選出新的主節(jié)點(diǎn)
通訊正常
優(yōu)先級(jí)排序
優(yōu)先級(jí)相同時(shí)選擇 offset 最大的

###將該節(jié)點(diǎn)設(shè)置成新的主節(jié)點(diǎn)SLAVEOF no one,并確保在后續(xù)的INGO命令時(shí) 該節(jié)點(diǎn)返回狀態(tài)為master 
###將其他的從節(jié)點(diǎn)設(shè)置成從新的主節(jié)點(diǎn)復(fù)制，SLAVEOF命令
###將舊的主節(jié)點(diǎn)變成新的主節(jié)點(diǎn)的從節(jié)點(diǎn)

PS:優(yōu)缺點(diǎn)
#優(yōu)點(diǎn):
高可用，哨兵模式是基于主從模式的，所有主從模式的優(yōu)點(diǎn)，哨兵模式都具有有;主從可以自動(dòng)切換，系統(tǒng)更健壯，可用性更高

#缺點(diǎn):
redis 比較難支持在線擴(kuò)容，在群集容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜

三、集群

1. redis 集群的含義

主節(jié)點(diǎn)負(fù)責(zé)讀寫(xiě)請(qǐng)求和集群信息的維護(hù)，從節(jié)點(diǎn)只進(jìn)行主節(jié)點(diǎn)數(shù)據(jù)和狀態(tài)信息的復(fù)制

??redis 的哨兵模式基本已經(jīng)可以實(shí)現(xiàn)高可用、讀寫(xiě)分離，但是在這種模式每臺(tái) redis 服務(wù)器都存儲(chǔ)相同的數(shù)據(jù)，很浪費(fèi)內(nèi)存資源，所以在 redis3.0 上加入了 Cluster 群集模式，實(shí)現(xiàn)了 redis 的分布式存儲(chǔ)，也就是說(shuō)每臺(tái) redis 節(jié)點(diǎn)存儲(chǔ)著不同的內(nèi)容。根據(jù)官方推薦，集群部署至少要 3 臺(tái)以上的 master 節(jié)點(diǎn)，最好使用 3 主 3 從六個(gè)節(jié)點(diǎn)的模式。
??Cluster 群集由多個(gè) redis 服務(wù)器組成的分布式網(wǎng)絡(luò)服務(wù)群集，群集之中有多個(gè) master 主節(jié)點(diǎn)，每一個(gè)主節(jié)點(diǎn)都可讀可寫(xiě)，節(jié)點(diǎn)之間會(huì)相互通信，兩兩相連，redis 群集無(wú)中心節(jié)點(diǎn)。

2. redis 集群的特點(diǎn)

• 在 redis-Cluster 群集中，可以給每個(gè)一個(gè)主節(jié)點(diǎn)添加從節(jié)點(diǎn)，主節(jié)點(diǎn)和從節(jié)點(diǎn)直接尊循主從模型的特性，當(dāng)用戶需要處理更多讀請(qǐng)求的時(shí)候，添加從節(jié)點(diǎn)可以擴(kuò)展系統(tǒng)的讀性能

• redis-cluster 的故障轉(zhuǎn)移：redis 群集的主機(jī)節(jié)點(diǎn)內(nèi)置了類似 redis sentinel 的節(jié)點(diǎn)故障檢測(cè)和自動(dòng)故障轉(zhuǎn)移功能，當(dāng)群集中的某個(gè)主節(jié)點(diǎn)下線時(shí)，群集中的其他在線主節(jié)點(diǎn)會(huì)注意到這一點(diǎn)，并且對(duì)已經(jīng)下線的主節(jié)點(diǎn)進(jìn)行故障轉(zhuǎn)移

• 集群進(jìn)行故障轉(zhuǎn)移的方法和 redis sentinel 進(jìn)行故障轉(zhuǎn)移的方法基本一樣，不同的是，在集群里面，故障轉(zhuǎn)移是由集群中其他在線的主節(jié)點(diǎn)負(fù)責(zé)進(jìn)行的，所以群集不必另外使用 redis sentinel

四、分布式鎖

https://www.zhihu.com/question/300767410/answer/1749442787
??如果在一個(gè)分布式系統(tǒng)中，我們從數(shù)據(jù)庫(kù)中讀取一個(gè)數(shù)據(jù)，然后修改保存，這種情況很容易遇到并發(fā)問(wèn)題。因?yàn)樽x取和更新保存不是一個(gè)原子操作，在并發(fā)時(shí)就會(huì)導(dǎo)致數(shù)據(jù)的不正確。這種場(chǎng)景其實(shí)并不少見(jiàn)，比如電商秒殺活動(dòng)，庫(kù)存數(shù)量的更新就會(huì)遇到。如果是單機(jī)應(yīng)用，直接使用本地鎖就可以避免。如果是分布式應(yīng)用，本地鎖派不上用場(chǎng)，這時(shí)就需要引入分布式鎖來(lái)解決。由此可見(jiàn)分布式鎖的目的其實(shí)很簡(jiǎn)單，就是為了保證多臺(tái)服務(wù)器在執(zhí)行某一段代碼時(shí)保證只有一臺(tái)服務(wù)器執(zhí)行。

簡(jiǎn)單來(lái)說(shuō)：
??現(xiàn)在的業(yè)務(wù)應(yīng)用通常都是微服務(wù)架構(gòu)，這也意味著一個(gè)應(yīng)用會(huì)部署多個(gè)進(jìn)程，那么多個(gè)進(jìn)程如果需要修改數(shù)據(jù)庫(kù)中的同一行記錄時(shí)，為了避免操作亂序?qū)е聰?shù)據(jù)錯(cuò)誤，此時(shí)就需要引入分布式鎖解決問(wèn)題。

為了保證分布式鎖的可用性，至少要確保鎖的實(shí)現(xiàn)要同時(shí)滿足以下幾點(diǎn)：

• 互斥性。在任何時(shí)刻，保證只有一個(gè)客戶端持有鎖。

• 不能出現(xiàn)死鎖。如果在一個(gè)客戶端持有鎖的期間，這個(gè)客戶端崩潰了，也要保證后續(xù)的其他客戶端可以上鎖。

• 保證上鎖和解鎖都是同一個(gè)客戶端。

一般來(lái)說(shuō)，實(shí)現(xiàn)分布式鎖的方式有以下幾種：

• 使用 MySQL，基于唯一索引。

• 使用 ZooKeeper，基于臨時(shí)有序節(jié)點(diǎn)。

• 使用 Redis，基于 setnx 命令。

對(duì) redis 來(lái)說(shuō)注意三點(diǎn)，對(duì) key 的加鎖，如果請(qǐng)求未完成對(duì)快要過(guò)期的 key 的續(xù)期，請(qǐng)求完成后 key 的解鎖。防止并發(fā)環(huán)境下被讀取的一個(gè) key 可能被多個(gè)請(qǐng)求修改，造成無(wú)效操作，資源浪費(fèi)的情況。

五、redis 總結(jié)

• redis 可以做為 mysql 的前置緩存數(shù)據(jù)庫(kù)，redis 與 mysql 對(duì)接的方式需要配置線程池，需要定義后端 mysql 的位置（ IP + port ＋sock 文件的位置）

• redis 基礎(chǔ)功能：用于內(nèi)存/緩存的快速存儲(chǔ)（讀?。?/p>

• 實(shí)現(xiàn)的方式：

默認(rèn)將數(shù)據(jù)存儲(chǔ)在內(nèi)存/緩存中
具有豐富的數(shù)據(jù)類型：string list hash set && order set 等
重要數(shù)據(jù)持久化的功能，持久化的方式：AOF RDB

單線程模式 -> 速度快的原因之一：Epoll + I/O 復(fù)用（cluster 中的 slots 哈希槽可以充當(dāng)數(shù)據(jù)讀、取的索引)

• redis 中的算法：

LRU：淘汰策略
1) 緩存中的數(shù)據(jù)進(jìn)行隨機(jī)淘汰
2) 緩存中被設(shè)置了過(guò)期時(shí)間的數(shù)據(jù)進(jìn)行隨機(jī)淘汰
3) 緩存中被設(shè)置了過(guò)期時(shí)間的數(shù)據(jù)，進(jìn)行惰性刪除（僅當(dāng)訪問(wèn)到的數(shù)據(jù)過(guò)期了，才會(huì)刪除）
4) 當(dāng)數(shù)據(jù)持續(xù)存儲(chǔ)過(guò)程中內(nèi)存將滿，會(huì)在設(shè)置了過(guò)期時(shí)間的數(shù)據(jù)中進(jìn)行近期淘汰

令牌桶 + 漏桶算法：限流
Raft：選舉機(jī)制，用于選舉新的主節(jié)點(diǎn)

• redis 緩存高熱數(shù)據(jù)的機(jī)制

高熱數(shù)據(jù)：命中次數(shù)高的數(shù)據(jù)
指定提高緩存內(nèi)數(shù)據(jù)的命中數(shù)，最直接的可以刷腳本，訪問(wèn)這些數(shù)據(jù)

六、系統(tǒng)優(yōu)化

1. 單例服務(wù)器，服務(wù)器本身優(yōu)化

硬件資源選擇（系統(tǒng)五大資源）

• 磁盤(pán) 固態(tài)盤(pán) SCSI（硬件磁盤(pán)陣列）

• 服務(wù)器內(nèi)存條選擇（本地服務(wù)器和云服務(wù)器）

• CPU 核數(shù)選擇

• 網(wǎng)絡(luò)網(wǎng)卡（本地服務(wù)器和云服務(wù)器），需要考慮負(fù)載壓力下的網(wǎng)絡(luò)流量 QPS

• 服務(wù)器選型（麒麟、曉龍、浪潮英信、華為、華三、戴爾（類型：刀片、塔式、機(jī)柜））

以上需要計(jì)算費(fèi)用成本，還需要考慮到該服務(wù)器上的服務(wù)在運(yùn)行時(shí)消耗的性能比例（需要預(yù)留給系統(tǒng)一部分資源）

服務(wù)本身環(huán)境的選擇

• 操作系統(tǒng)選擇 Linux 發(fā)行版：centos ubuntu redhat server debian alphon mac SUSE（PS：虛擬化 KVM XEN FUFE）

• 基于操作系統(tǒng)，依賴環(huán)境。選擇最小化安裝還是指定操作系統(tǒng)版本的安裝 + 指定內(nèi)核版本。軟件是否有依賴（例如：tomcat 需要 JDK，編譯需要 gcc gcc-c++ pcre …）

• 軟件資源優(yōu)化 五大負(fù)載＋內(nèi)核優(yōu)化（TCP協(xié)議相關(guān)、隊(duì)列相關(guān)、路由轉(zhuǎn)發(fā)、重定向、端口、文件打開(kāi)數(shù)、系統(tǒng)的軟硬限制等）

2. 單例服務(wù)器應(yīng)用服務(wù)本身優(yōu)化

以 redis 為例

首先從啟動(dòng)讀取的恢復(fù)文件來(lái)看，基于AOF需要開(kāi)啟 AOF功能（RDB 默認(rèn)）

• RDB 中 save M N 觸發(fā)周期的選擇判定，這會(huì)影響到磁盤(pán)資源的使用

• AOF 中選擇合適的 syncwrite 同步寫(xiě)入磁盤(pán)的策略 everysecond

使用過(guò)程中，需要考慮到的是內(nèi)存的使用量（ OOM ）

• 內(nèi)存淘汰策略：惰性淘汰＋定期刪除，禁止淘汰＋定期刪除。根據(jù)情況選擇合適的淘汰策略（配置文件中定義）。

持久化方向
持久化的功能在保證數(shù)據(jù)完整性的同時(shí)，依然會(huì)持續(xù)性的對(duì)磁盤(pán)產(chǎn)生存儲(chǔ)壓力（壓力來(lái)源于 AOF 和 RDB 生成的數(shù)據(jù)文件，AOF 和 RDB 的日志文件）。

• 數(shù)據(jù)/日志文件的定期歸檔

• 日志文件的分割（保存在日志中心）

• 共享存儲(chǔ) NFS GFS fastDFS

redis主進(jìn)程

• 可以使用兩個(gè) redis 主進(jìn)程配合實(shí)現(xiàn)備份冗余，提高抗高并發(fā)的能力

關(guān)于“redis中主從復(fù)制、哨兵、集群的原理是什么”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“redis中主從復(fù)制、哨兵、集群的原理是什么”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。