歡迎關(guān)注公眾號(hào)：「碼農(nóng)富哥」，致力于分享后端技術(shù) (高并發(fā)架構(gòu)，分布式集群系統(tǒng)，消息隊(duì)列中間件，網(wǎng)絡(luò)，微服務(wù)，Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原創(chuàng)干貨 和 面試指南！

免費(fèi)視頻福利推薦：

2T學(xué)習(xí)視頻教程+電子書 免費(fèi)送：BAT面試精講視頻，億級(jí)流量秒殺系統(tǒng)，分布式系統(tǒng)架構(gòu)，中間件消息隊(duì)列，Python Go入門到精通，Java實(shí)戰(zhàn)項(xiàng)目，Linux， 網(wǎng)絡(luò)，MySQL高性能，Redis集群架構(gòu)，大數(shù)據(jù)，架構(gòu)師速成，微服務(wù)，容器化Docker K8s， ELK Stack日志系統(tǒng)等免費(fèi)視頻教程！

Redis高可用概述

在介紹Redis高可用之前，先說明一下在Redis的語境中高可用的含義。

我們知道，在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長(zhǎng)時(shí)間內(nèi)可以提供正常服務(wù)（99.9%、99.99%、99.999% 等等）。但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)(如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴(kuò)展、數(shù)據(jù)安全不會(huì)丟失等。

在Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、復(fù)制、哨兵和集群，下面分別說明它們的作用，以及解決了什么樣的問題。

• 持久化：持久化是最簡(jiǎn)單的高可用方法(有時(shí)甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲(chǔ)在硬盤，保證數(shù)據(jù)不會(huì)因進(jìn)程退出而丟失。
• 復(fù)制：復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在復(fù)制基礎(chǔ)上實(shí)現(xiàn)高可用的。復(fù)制主要實(shí)現(xiàn)了數(shù)據(jù)的多機(jī)備份，以及對(duì)于讀操作的負(fù)載均衡和簡(jiǎn)單的故障恢復(fù)。缺陷：故障恢復(fù)無法自動(dòng)化；寫操作無法負(fù)載均衡；存儲(chǔ)能力受到單機(jī)的限制。
• 哨兵：在復(fù)制的基礎(chǔ)上，哨兵實(shí)現(xiàn)了自動(dòng)化的故障恢復(fù)。缺陷：寫操作無法負(fù)載均衡；存儲(chǔ)能力受到單機(jī)的限制。
• 集群：通過集群，Redis解決了寫操作無法負(fù)載均衡，以及存儲(chǔ)能力受到單機(jī)限制的問題，實(shí)現(xiàn)了較為完善的高可用方案。

Redis持久化概述

Redis 的數(shù)據(jù)全部在內(nèi)存里，如果突然宕機(jī)，數(shù)據(jù)就會(huì)全部丟失，因此必須有一種機(jī)制來保證 Redis 的數(shù)據(jù)不會(huì)因?yàn)楣收隙鴣G失，這種機(jī)制就是 Redis 的持久化機(jī)制。

Redis為持久化提供了兩種方式：

• RDB：在指定的時(shí)間間隔能對(duì)你的數(shù)據(jù)進(jìn)行快照存儲(chǔ)。
• AOF：記錄每次對(duì)服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)。

由于AOF持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

下面依次介紹RDB持久化和AOF持久化；

RDB持久化

RDB是默認(rèn)的持久化方式，按照一定的策略周期性的將內(nèi)存中的數(shù)據(jù)生成快照保存到磁盤。

每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會(huì)引起大量的磁盤io操作，可能會(huì)嚴(yán)重影響性能。

1. 工作原理：

• Redis調(diào)用fork()，產(chǎn)生一個(gè)子進(jìn)程。
• 子進(jìn)程把數(shù)據(jù)寫到一個(gè)臨時(shí)的RDB文件。
• 當(dāng)子進(jìn)程寫完新的RDB文件后，把舊的RDB文件替換掉。

2. 觸發(fā)機(jī)制

RDB觸發(fā)持久化分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)

1. save 命令（手動(dòng)觸發(fā)）

當(dāng)客戶端向Redis server發(fā)送save命令請(qǐng)求進(jìn)行持久化時(shí)，由于Redis是用一個(gè)主線程來處理所有，save命令會(huì)阻塞Redis server處理其他客戶端的請(qǐng)求，直到數(shù)據(jù)同步完成。save命令會(huì)阻塞Redis服務(wù)器進(jìn)程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請(qǐng)求，因此線上環(huán)境不推薦使用

2. bgsave命令（手動(dòng)觸發(fā)）

與save命令不同，bgsave是異步執(zhí)行的，當(dāng)執(zhí)行bgsave命令之后，Redis主進(jìn)程會(huì)fork 一個(gè)子進(jìn)程將數(shù)據(jù)保存到rdb文件中，同步完數(shù)據(jù)之后，對(duì)原有文件進(jìn)行替換，然后通知主進(jìn)程表示同步完成。

3. 自動(dòng)觸發(fā)

除了手動(dòng)觸發(fā)RDB持久化，Redis內(nèi)部還存在自動(dòng)觸發(fā)機(jī)制，

在配置中集中配置 save m n 的方式，表示 m秒內(nèi)數(shù)據(jù)集存在n次修改時(shí)，系統(tǒng)自動(dòng)觸發(fā)bgsave 操作。

3. RDB自動(dòng)持久化配置

# 時(shí)間策略
save 900 1
save 300 10
save 60 10000

# 文件名稱
dbfilename dump.rdb

# 文件保存路徑
dir /etc/redis/data/

# 如果持久化出錯(cuò)，主進(jìn)程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

# 導(dǎo)入時(shí)是否檢查
rdbchecksum yes
rdb持久化策略比較簡(jiǎn)單，下面解釋一下：

save 900 1表示900s內(nèi)如果有1條是寫入命令，就觸發(fā)產(chǎn)生一次快照，可以理解為就進(jìn)行一次備份
save 300 10表示300s內(nèi)有10條寫入，就產(chǎn)生快照
下面的類似，那么為什么需要配置這么多條規(guī)則呢？因?yàn)镽edis每個(gè)時(shí)段的讀寫請(qǐng)求肯定不是均衡的，為了平衡性能與數(shù)據(jù)安全，我們可以自由定制什么情況下觸發(fā)備份。所以這里就是根據(jù)自身Redis寫入情況來進(jìn)行合理配置。

stop-writes-on-bgsave-error yes這個(gè)配置也是非常重要的一項(xiàng)配置，這是當(dāng)備份進(jìn)程出錯(cuò)時(shí)，主進(jìn)程就停止接受新的寫入操作，是為了保護(hù)持久化的數(shù)據(jù)一致性問題。如果自己的業(yè)務(wù)有完善的監(jiān)控系統(tǒng)，可以禁止此項(xiàng)配置， 否則請(qǐng)開啟。

rdbcompression yes 用于配置是否壓縮RDB文件，建議沒有必要開啟，畢竟Redis本身就屬于CPU密集型服務(wù)器，再開啟壓縮會(huì)帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。

rdbchecksum yes 是否開啟RDB文件的校驗(yàn)，在寫入文件和讀取文件時(shí)都起作用；關(guān)閉checksum在寫入文件和啟動(dòng)文件時(shí)大約能帶來10%的性能提升，但是數(shù)據(jù)損壞時(shí)無法發(fā)現(xiàn)

dbfilename dump.rdb RDB文件名

dir ./ RDB文件和AOF文件所在目錄

當(dāng)然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行寫上：save ""

4. 執(zhí)行流程圖

RDB執(zhí)行流程圖

1. Redis父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof（后面會(huì)詳細(xì)介紹該命令）的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮：兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題。

2. 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令

3. 父進(jìn)程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令

4. 子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時(shí)快照文件，完成后對(duì)原有文件進(jìn)行原子替換

5. 子進(jìn)程發(fā)送信號(hào)給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息

5. 數(shù)據(jù)恢復(fù) & Redis啟動(dòng)加載數(shù)據(jù)

RDB文件的載入工作是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級(jí)更高，因此當(dāng)AOF開啟時(shí)，Redis會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；

只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)在Redis服務(wù)器啟動(dòng)時(shí)檢測(cè)RDB文件，并自動(dòng)載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。

所以Redis的內(nèi)存數(shù)據(jù)如果很大，會(huì)導(dǎo)致數(shù)據(jù)恢復(fù)時(shí)間比較長(zhǎng)，因此線上實(shí)踐更傾向于限制單個(gè)Redis的內(nèi)存不能太大，同時(shí)結(jié)合Redis Cluster集群使用多節(jié)點(diǎn)部署

Redis啟動(dòng)日志中可以看到自動(dòng)載入的執(zhí)行：

RDB載入過程

Redis載入RDB文件時(shí)，會(huì)對(duì)RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。

大家如果更系統(tǒng)了解Redis 高可用集群架構(gòu)知識(shí)，可以關(guān)注公眾號(hào)【碼農(nóng)富哥】后回復(fù)【Redis】獲取 Redis高可用集群架構(gòu)視頻

AOF持久化

RDB快照并不是很可靠。如果你的電腦突然宕機(jī)了，或者電源斷了，又或者不小心殺掉了進(jìn)程，那么最新的數(shù)據(jù)就會(huì)丟失。而AOF文件則提供了一種更為可靠的持久化方式。每當(dāng)Redis接受到會(huì)修改數(shù)據(jù)集的命令時(shí)，就會(huì)把命令追加到AOF文件里，當(dāng)你重啟Redis時(shí)，AOF里的命令會(huì)被重新執(zhí)行一次，重建數(shù)據(jù)。

1.工作原理

由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)， AOF的執(zhí)行流程包括：

• 命令追加(append)：將Redis的寫命令追加到緩沖區(qū)aof_buf；
• 文件寫入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤；

• 文件重寫(rewrite)：定期重寫AOF文件，達(dá)到壓縮的目的。

  
  
  AOF執(zhí)行流程

2. AOF 持久化配置

# 是否開啟aof
appendonly yes

# 文件名稱
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重寫期間是否同步
no-appendfsync-on-rewrite no

# 重寫觸發(fā)配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加載aof時(shí)如果有錯(cuò)如何處理
aof-load-truncated yes

# 文件重寫策略
aof-rewrite-incremental-fsync yes

3. AOF同步策略

同步步驟分為兩步：

• Redis收到寫命令后首先會(huì)追加到AOF緩沖區(qū)aof_buf，而不是直接寫入文件系統(tǒng)，因?yàn)锳OF緩沖區(qū)是內(nèi)存提存的，寫入速度極高，可以避免每次寫入命令到硬盤，導(dǎo)致硬盤IO成為Redis的負(fù)載瓶頸
• 通過調(diào)用系統(tǒng)函數(shù) fsync() 把AOF緩沖區(qū)的數(shù)據(jù)真正寫到磁盤里面持久化。由于數(shù)據(jù)是先存儲(chǔ)在緩沖區(qū)內(nèi)存里面，如果碰到斷電，宕機(jī)那么緩沖區(qū)里面的數(shù)據(jù)沒來得急落盤就會(huì)丟失，因此我們必須有一個(gè)相對(duì)可靠的機(jī)制保證數(shù)據(jù)落盤。

Redis寫命令寫入磁盤的命令是通過appendfsync來配置的。
appendfsync 三個(gè)取值代表三種落盤策略:

• always：命令寫入aof緩沖區(qū)后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸。
• no：命令寫入aof緩沖區(qū)后調(diào)用系統(tǒng)write操作，不對(duì)AOF文件做fsync同步；同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多，數(shù)據(jù)安全性無法保證。
• everysec：命令寫入aof緩沖區(qū)后調(diào)用系統(tǒng)write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置，也是我們推薦的配置。

4. AOF文件重寫(rewrite)

隨著寫操作的不斷增加，AOF文件會(huì)越來越大。例如你遞增一個(gè)計(jì)數(shù)器100次，那么最終結(jié)果就是數(shù)據(jù)集里的計(jì)數(shù)器的值為最終的遞增結(jié)果，但是AOF文件里卻會(huì)把這100次操作完整的記錄下來。而事實(shí)上要恢復(fù)這個(gè)記錄，只需要1個(gè)命令就行了，也就是說AOF文件里那100條命令其實(shí)可以精簡(jiǎn)為1條。所以Redis支持這樣一個(gè)功能：在不中斷服務(wù)的情況下在后臺(tái)重建AOF文件。

AOF重寫流程：

AOF重寫流程

關(guān)于文件重寫的流程，有兩點(diǎn)需要特別注意：

(1)重寫由父進(jìn)程fork子進(jìn)程進(jìn)行；

(2)重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。

對(duì)照上圖，文件重寫的流程如下：

1. Redis父進(jìn)程首先判斷當(dāng)前是否存在正在執(zhí)行 bgsave/bgrewriteaof的子進(jìn)程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。前面曾介紹過，這個(gè)主要是基于性能方面的考慮。

2. 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(jìn)程是阻塞的。

3.1) 父進(jìn)程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機(jī)制的正確。

3.2) 由于fork操作使用寫時(shí)復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時(shí)的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)(圖中的aof_rewrite_buf)保存這部分?jǐn)?shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時(shí)追加到aof_buf和aof_rewirte_buf兩個(gè)緩沖區(qū)。

4. 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。

5.1) 子進(jìn)程寫完新的AOF文件后，向父進(jìn)程發(fā)信號(hào)，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過info persistence查看。

5.2) 父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。

5.3) 使用新的AOF文件替換老文件，完成AOF重寫。

重寫觸發(fā)：

1. 手動(dòng)觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時(shí)阻塞。

2. 自動(dòng)觸發(fā)：通過配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size來完成

auto-aof-rewrite-percentage 100 ：Redis會(huì)記住自從上一次重寫后AOF文件的大?。ㄈ绻訰edis啟動(dòng)后還沒重寫過，則記住啟動(dòng)時(shí)使用的AOF文件的大?。?。如果當(dāng)前的文件大小比起記住的那個(gè)大小超過指定的百分比，則會(huì)觸配置發(fā)重寫。

auto-aof-rewrite-min-size 64mb：同時(shí)需要設(shè)置一個(gè)文件大小最小值，只有大于這個(gè)值文件才會(huì)重寫，以防文件很小，但是已經(jīng)達(dá)到百分比的情況。

要禁用自動(dòng)的日志重寫功能，我們可以把百分比設(shè)置為0：

auto-aof-rewrite-percentage 0： 禁用日志重寫功能

5. 數(shù)據(jù)恢復(fù) & Redis啟動(dòng)加載數(shù)據(jù)

前面提到過，當(dāng)AOF開啟時(shí)，Redis啟動(dòng)時(shí)會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；

只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)載入RDB文件恢復(fù)數(shù)據(jù)。

當(dāng)AOF開啟，且AOF文件存在時(shí)，Redis啟動(dòng)日志：

image

持久化方案選擇

1. RDB和AOF的優(yōu)缺點(diǎn)

RDB和AOF各有優(yōu)缺點(diǎn)：

RDB持久化

• 優(yōu)點(diǎn)：RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比，RDB最重要的優(yōu)點(diǎn)之一是對(duì)性能的影響相對(duì)較小。

• 缺點(diǎn)：RDB文件的致命缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

• 與RDB持久化相對(duì)應(yīng)，AOF的優(yōu)點(diǎn)在于支持秒級(jí)持久化、兼容性好，缺點(diǎn)是文件大、恢復(fù)速度慢、對(duì)性能影響大。

2. 性能與實(shí)踐

通過上面的分析，我們都知道RDB的快照、AOF的重寫都需要fork，這是一個(gè)重量級(jí)操作，會(huì)對(duì)Redis造成阻塞。因此為了不影響Redis主進(jìn)程響應(yīng)，我們需要盡可能降低阻塞。

• 降低fork的頻率，比如可以手動(dòng)來觸發(fā)RDB生成快照、與AOF重寫；
• 控制Redis最大使用內(nèi)存，防止fork耗時(shí)過長(zhǎng)；
• 使用更牛逼的硬件；
• 合理配置Linux的內(nèi)存分配策略，避免因?yàn)槲锢韮?nèi)存不足導(dǎo)致fork失敗。

在線上我們到底該怎么做？我提供一些自己的實(shí)踐經(jīng)驗(yàn)。

• 如果Redis中的數(shù)據(jù)并不是特別敏感或者可以通過其它方式重寫生成數(shù)據(jù)，可以關(guān)閉持久化，如果丟失數(shù)據(jù)可以通過其它途徑補(bǔ)回；
• 自己制定策略定期檢查Redis的情況，然后可以手動(dòng)觸發(fā)備份、重寫數(shù)據(jù)；
• 單機(jī)如果部署多個(gè)實(shí)例，要防止多個(gè)機(jī)器同時(shí)運(yùn)行持久化、重寫操作，防止出現(xiàn)內(nèi)存、CPU、IO資源競(jìng)爭(zhēng)，讓持久化變?yōu)榇校?/li>
• 可以加入主從機(jī)器，利用一臺(tái)從機(jī)器進(jìn)行備份處理，其它機(jī)器正常響應(yīng)客戶端的命令；
• RDB持久化與AOF持久化可以同時(shí)存在，配合使用。

總結(jié)

Redis的高可用系列：持久化就已經(jīng)講完了，持久化主要有RDB和AOF兩種技術(shù)，大家按照上面所介紹的原理和流程，根據(jù)線上具體需求選擇適合自己的持久化方案。

另外，寫原創(chuàng)技術(shù)文章不易，要花費(fèi)好多時(shí)間和精力，希望大家看到文章也能有所收獲！你們的點(diǎn)贊和收藏就能成為我繼續(xù)堅(jiān)持輸出原創(chuàng)文章的動(dòng)力！大家也可以關(guān)注我的公眾號(hào)，訂閱更多我的文章！

歡迎關(guān)注公眾號(hào)：「碼農(nóng)富哥」，致力于分享后端技術(shù) (高并發(fā)架構(gòu)，分布式集群系統(tǒng)，消息隊(duì)列中間件，網(wǎng)絡(luò)，微服務(wù)，Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原創(chuàng)干貨 和 面試指南！
關(guān)注公眾號(hào)后回復(fù)【資源】免費(fèi)獲取 2T 編程視頻和電子書，回復(fù)【Redis】獲取 Redis高可用集群架構(gòu)視頻

image