在這篇文章，我們一起了解 redis 使用中非常重要的兩個(gè)機(jī)制：Reids 持久化和主從復(fù)制。
圖片來自 Unsplash
什么是 Redis 持久化?
Redis 作為一個(gè)鍵值對(duì)內(nèi)存數(shù)據(jù)庫(NoSQL)，數(shù)據(jù)都存儲(chǔ)在內(nèi)存當(dāng)中，在處理客戶端請(qǐng)求時(shí)，所有操作都在內(nèi)存當(dāng)中進(jìn)行，如下所示：
這樣做有什么問題呢?其實(shí)，只要稍微有點(diǎn)計(jì)算機(jī)基礎(chǔ)知識(shí)的人都知道，存儲(chǔ)在內(nèi)存當(dāng)中的數(shù)據(jù)，只要服務(wù)器關(guān)機(jī)(各種原因引起的)，內(nèi)存中的數(shù)據(jù)就會(huì)消失了。
不僅服務(wù)器關(guān)機(jī)會(huì)造成數(shù)據(jù)消失，Redis 服務(wù)器守護(hù)進(jìn)程退出，內(nèi)存中的數(shù)據(jù)也一樣會(huì)消失。
對(duì)于只把 Redis 當(dāng)緩存來用的項(xiàng)目來說，數(shù)據(jù)消失或許問題不大，重新從數(shù)據(jù)源把數(shù)據(jù)加載進(jìn)來就可以了。
但如果直接把用戶提交的業(yè)務(wù)數(shù)據(jù)存儲(chǔ)在 Redis 當(dāng)中，把 Redis 作為數(shù)據(jù)庫來使用，在其放存儲(chǔ)重要業(yè)務(wù)數(shù)據(jù)，那么 Redis 的內(nèi)存數(shù)據(jù)丟失所造成的影響也許是毀滅性。
為了避免內(nèi)存中數(shù)據(jù)丟失，Redis 提供了對(duì)持久化的支持，我們可以選擇不同的方式將數(shù)據(jù)從內(nèi)存中保存到硬盤當(dāng)中，使數(shù)據(jù)可以持久化保存。
Redis 提供了 RDB 和 AOF 兩種不同的數(shù)據(jù)持久化方式，下面我們就來詳細(xì)介紹一下這種不同的持久化方式吧。
RDB
RDB 是一種快照存儲(chǔ)持久化方式，具體就是將 Redis 某一時(shí)刻的內(nèi)存數(shù)據(jù)保存到硬盤的文件當(dāng)中，默認(rèn)保存的文件名為 dump.rdb，而在 Redis 服務(wù)器啟動(dòng)時(shí)，會(huì)重新加載 dump.rdb 文件的數(shù)據(jù)到內(nèi)存當(dāng)中恢復(fù)數(shù)據(jù)。
①開啟 RDB 持久化方式
開啟 RDB 持久化方式很簡(jiǎn)單，客戶端可以通過向 Redis 服務(wù)器發(fā)送 Save 或 Bgsave 命令讓服務(wù)器生成 RDB 文件，或者通過服務(wù)器配置文件指定觸發(fā) RDB 條件。
save 命令：是一個(gè)同步操作。
# 同步數(shù)據(jù)到磁盤上 > save
當(dāng)客戶端向服務(wù)器發(fā)送 Save 命令請(qǐng)求進(jìn)行持久化時(shí)，服務(wù)器會(huì)阻塞 Save 命令之后的其他客戶端的請(qǐng)求，直到數(shù)據(jù)同步完成。
如果數(shù)據(jù)量太大，同步數(shù)據(jù)會(huì)執(zhí)行很久，而這期間 Redis 服務(wù)器也無法接收其他請(qǐng)求，所以，最好不要在生產(chǎn)環(huán)境使用 Save 命令。
Bgsave：與 Save 命令不同，Bgsave 命令是一個(gè)異步操作。
# 異步保存數(shù)據(jù)集到磁盤上 > bgsave
當(dāng)客戶端發(fā)服務(wù)發(fā)出 Bgsave 命令時(shí)，Redis 服務(wù)器主進(jìn)程會(huì) Forks 一個(gè)子進(jìn)程來數(shù)據(jù)同步問題，在將數(shù)據(jù)保存到 RDB 文件之后，子進(jìn)程會(huì)退出。
所以，與 Save 命令相比，Redis 服務(wù)器在處理 Bgsave 采用子線程進(jìn)行 IO 寫入。
而主進(jìn)程仍然可以接收其他請(qǐng)求，但 Forks 子進(jìn)程是同步的，所以 Forks 子進(jìn)程時(shí)，一樣不能接收其他請(qǐng)求。
這意味著，如果 Forks 一個(gè)子進(jìn)程花費(fèi)的時(shí)間太久(一般是很快的)，Bgsave 命令仍然有阻塞其他客戶的請(qǐng)求的情況發(fā)生。
服務(wù)器配置自動(dòng)觸發(fā)：除了通過客戶端發(fā)送命令外，還有一種方式，就是在 Redis 配置文件中的 Save 指定到達(dá)觸發(fā) RDB 持久化的條件，比如【多少秒內(nèi)至少達(dá)到多少寫操作】就開啟 RDB 數(shù)據(jù)同步。
例如我們可以在配置文件 redis.conf 指定如下的選項(xiàng)：
# 900s內(nèi)至少達(dá)到一條寫命令 save 900 1 # 300s內(nèi)至少達(dá)至10條寫命令 save 300 10 # 60s內(nèi)至少達(dá)到10000條寫命令 save 60 10000
之后在啟動(dòng)服務(wù)器時(shí)加載配置文件。
# 啟動(dòng)服務(wù)器加載配置文件 redis-server redis.conf
這種通過服務(wù)器配置文件觸發(fā) RDB 的方式，與 Bgsave 命令類似，達(dá)到觸發(fā)條件時(shí)，會(huì) Forks 一個(gè)子進(jìn)程進(jìn)行數(shù)據(jù)同步。
不過最好不要通過這方式來觸發(fā) RDB 持久化，因?yàn)樵O(shè)置觸發(fā)的時(shí)間太短，則容易頻繁寫入 RDB 文件，影響服務(wù)器性能，時(shí)間設(shè)置太長(zhǎng)則會(huì)造成數(shù)據(jù)丟失。
②RDB 文件
前面介紹了三種讓服務(wù)器生成 RDB 文件的方式，無論是由主進(jìn)程生成還是子進(jìn)程來生成，其過程如下：
- 生成臨時(shí) RDB 文件，并寫入數(shù)據(jù)。
- 完成數(shù)據(jù)寫入，用臨時(shí)文代替代正式 RDB 文件。
- 刪除原來的 DB 文件。
RDB 默認(rèn)生成的文件名為 dump.rdb，當(dāng)然，我可以通過配置文件進(jìn)行更加詳細(xì)配置。
比如在單機(jī)下啟動(dòng)多個(gè) Redis 服務(wù)器進(jìn)程時(shí)，可以通過端口號(hào)配置不同的 RDB 名稱，如下所示：
# 是否壓縮rdb文件 rdbcompression yes # rdb文件的名稱 dbfilename redis-6379.rdb # rdb文件保存目錄 dir ~/redis/
RDB的幾個(gè)優(yōu)點(diǎn)：
- 與 AOF 方式相比，通過 RDB 文件恢復(fù)數(shù)據(jù)比較快。
- RDB 文件非常緊湊，適合于數(shù)據(jù)備份。
- 通過 RDB 進(jìn)行數(shù)據(jù)備份，由于使用子進(jìn)程生成，所以對(duì) Redis 服務(wù)器性能影響較小。
RDB 的幾個(gè)缺點(diǎn)：
- 如果服務(wù)器宕機(jī)的話，采用 RDB 的方式會(huì)造成某個(gè)時(shí)段內(nèi)數(shù)據(jù)的丟失，比如我們?cè)O(shè)置 10 分鐘同步一次或 5 分鐘達(dá)到 1000 次寫入就同步一次，那么如果還沒達(dá)到觸發(fā)條件服務(wù)器就死機(jī)了，那么這個(gè)時(shí)間段的數(shù)據(jù)會(huì)丟失。
- 使用 Save 命令會(huì)造成服務(wù)器阻塞，直接數(shù)據(jù)同步完成才能接收后續(xù)請(qǐng)求。
- 使用 Bgsave 命令在 Forks 子進(jìn)程時(shí)，如果數(shù)據(jù)量太大，F(xiàn)orks 的過程也會(huì)發(fā)生阻塞，另外，F(xiàn)orks 子進(jìn)程會(huì)耗費(fèi)內(nèi)存。
AOF
聊完了 RDB，來聊聊 Redis 的另外一個(gè)持久化方式：AOF(Append-only file)。
與 RDB 存儲(chǔ)某個(gè)時(shí)刻的快照不同，AOF 持久化方式會(huì)記錄客戶端對(duì)服務(wù)器的每一次寫操作命令，并將這些寫操作以 Redis 協(xié)議追加保存到以后綴為 AOF 文件末尾。
在 Redis 服務(wù)器重啟時(shí)，會(huì)加載并運(yùn)行 AOF 文件的命令，以達(dá)到恢復(fù)數(shù)據(jù)的目的。
①開啟 AOF 持久化方式
Redis 默認(rèn)不開啟 AOF 持久化方式，我們可以在配置文件中開啟并進(jìn)行更加詳細(xì)的配置，如下面的 redis.conf 文件：
# 開啟aof機(jī)制 appendonly yes # aof文件名 appendfilename "appendonly.aof" # 寫入策略,always表示每個(gè)寫操作都保存到aof文件中,也可以是everysec或no appendfsync always # 默認(rèn)不重寫aof文件 no-appendfsync-on-rewrite no # 保存目錄 dir ~/redis/
②三種寫入策略
在上面的配置文件中，我們可以通過 appendfsync 選項(xiàng)指定寫入策略，有三個(gè)選項(xiàng)：
appendfsync always # appendfsync everysec # appendfsync no
always：客戶端的每一個(gè)寫操作都保存到 AOF 文件當(dāng)中，這種策略很安全，但是每個(gè)寫操作都有 IO 操作，所以也很慢。
everysec：appendfsync 的默認(rèn)寫入策略，每秒寫入一次 AOF 文件，因此，最多可能會(huì)丟失 1s 的數(shù)據(jù)。
no：Redis 服務(wù)器不負(fù)責(zé)寫入 AOF，而是交由操作系統(tǒng)來處理什么時(shí)候?qū)懭?AOF 文件。更快，但也是最不安全的選擇，不推薦使用。
③AOF 文件重寫
AOF 將客戶端的每一個(gè)寫操作都追加到 AOF 文件末尾，比如對(duì)一個(gè) Key 多次執(zhí)行 Incr 命令，這時(shí)候，AOF 保存每一次命令到 AOF 文件中，AOF 文件會(huì)變得非常大。
incr num 1 incr num 2 incr num 3 incr num 4 incr num 5 incr num 6 ... incr num 100000
AOF 文件太大，加載 AOF 文件恢復(fù)數(shù)據(jù)時(shí)，就會(huì)非常慢，為了解決這個(gè)問題，Redis 支持 AOF 文件重寫。
通過重寫 AOF，可以生成一個(gè)恢復(fù)當(dāng)前數(shù)據(jù)的最少命令集，比如上面的例子中那么多條命令，可以重寫為：
set num 100000
AOF 文件是一個(gè)二進(jìn)制文件，并不是像上面的例子一樣，直接保存每個(gè)命令，而使用 Redis 自己的格式，上面只是方便演示。
兩種重寫方式：通過在 redis.conf 配置文件中的選項(xiàng) no-appendfsync-on-rewrite 可以設(shè)置是否開啟重寫。
這種方式會(huì)在每次 Fsync 時(shí)都重寫，影響服務(wù)器性能，因此默認(rèn)值為 no，不推薦使用。
# 默認(rèn)不重寫aof文件 no-appendfsync-on-rewrite no
客戶端向服務(wù)器發(fā)送 bgrewriteaof 命令，也可以讓服務(wù)器進(jìn)行 AOF 重寫。
# 讓服務(wù)器異步重寫追加aof文件命令 > bgrewriteaof
AOF 重寫方式也是異步操作，即如果要寫入 AOF 文件，則 Redis 主進(jìn)程會(huì) Forks 一個(gè)子進(jìn)程來處理，如下所示：
重寫 AOF 文件的好處：
- 壓縮 AOF 文件，減少磁盤占用量。
- 將 AOF 的命令壓縮為最小命令集，加快了數(shù)據(jù)恢復(fù)的速度。
③AOF 文件損壞
在寫入 AOF 日志文件時(shí)，如果 Redis 服務(wù)器宕機(jī)，則 AOF 日志文件文件會(huì)出格式錯(cuò)誤。
在重啟 Redis 服務(wù)器時(shí)，Redis 服務(wù)器會(huì)拒絕載入這個(gè) AOF 文件，可以通過以下步驟修復(fù) AOF 并恢復(fù)數(shù)據(jù)：
- 備份現(xiàn)在 AOF 文件，以防萬一。
- 使用 redis-check-aof 命令修復(fù) AOF 文件，該命令格式如下：
# 修復(fù)aof日志文件 $ redis-check-aof -fix file.aof
- 重啟 Redis 服務(wù)器，加載已經(jīng)修復(fù)的 AOF 文件，恢復(fù)數(shù)據(jù)。
AOF 的優(yōu)點(diǎn)：
- AOF 只是追加日志文件，因此對(duì)服務(wù)器性能影響較小，速度比 RDB 要快，消耗的內(nèi)存較少。
AOF 的缺點(diǎn)：
- AOF 方式生成的日志文件太大，即使通過 AFO 重寫，文件體積仍然很大。
- 恢復(fù)數(shù)據(jù)的速度比 RDB 慢。
選擇 RDB 還是 AOF 呢?
通過上面的介紹，我們了解了 RDB 與 AOF 各自的優(yōu)點(diǎn)與缺點(diǎn)，到底要如何選擇呢?
通過下面的表示，我們可以從幾個(gè)方面對(duì)比一下 RDB 與 AOF，在應(yīng)用時(shí)，要根據(jù)自己的實(shí)際需求，選擇 RDB 或者 AOF。
其實(shí)，如果想要數(shù)據(jù)足夠安全，可以兩種方式都開啟，但兩種持久化方式同時(shí)進(jìn)行 IO 操作，會(huì)嚴(yán)重影響服務(wù)器性能，因此有時(shí)候不得不做出選擇。
當(dāng) RDB 與 AOF 兩種方式都開啟時(shí)，Redis 會(huì)優(yōu)先使用 AOF 日志來恢復(fù)數(shù)據(jù)，因?yàn)?AOF 保存的文件比 RDB 文件更完整。
小結(jié)：上面講了一大堆 Redis 的持久化機(jī)制的知識(shí)，其實(shí)，如果你只是單純把 Redis 作為緩存服務(wù)器，那么可以完全不用考慮持久化。
但是，在如今的大多數(shù)服務(wù)器架構(gòu)中，Redis 不單單只是扮演一個(gè)緩存服務(wù)器的角色，還可以作為數(shù)據(jù)庫，保存我們的業(yè)務(wù)數(shù)據(jù)，此時(shí)，我們則需要好好了解有關(guān) Redis 持久化策略的區(qū)別與選擇。
什么是 Reids 主從復(fù)制?
上面，我們了解了 Redis 兩種不同的持久化方式，Redis 服務(wù)器通過持久化，把 Redis 內(nèi)存中持久化到硬盤當(dāng)中，當(dāng) Redis 宕機(jī)時(shí)，我們重啟 Redis 服務(wù)器時(shí)，可以由 RDB 文件或 AOF 文件恢復(fù)內(nèi)存中的數(shù)據(jù)。
不過持久化后的數(shù)據(jù)仍然只在一臺(tái)機(jī)器上，因此當(dāng)硬件發(fā)生故障時(shí)，比如主板或 CPU 壞了，這時(shí)候無法重啟服務(wù)器，有什么辦法可以保證服務(wù)器發(fā)生故障時(shí)數(shù)據(jù)的安全性?或者可以快速恢復(fù)數(shù)據(jù)呢?
想做到這一點(diǎn)，我們需要再了解 Redis 另外一種機(jī)制：主從復(fù)制。
Redis 的主從復(fù)制機(jī)制是指可以讓從服務(wù)器(Slave)能精確復(fù)制主服務(wù)器(Master)的數(shù)據(jù)，如下圖所示：
上面的圖表示的是一臺(tái) Master 服務(wù)器與 Slave 服務(wù)器的情況，其實(shí)一臺(tái) Master 服務(wù)器也可以對(duì)應(yīng)多臺(tái) Slave 服務(wù)器，如下圖所示：
另外，Slave 服務(wù)器也可以有自己的 Slave 服務(wù)器，這樣的服務(wù)器稱為 Sub-Slave。
而這些 Sub-Slave 通過主從復(fù)制最終數(shù)據(jù)也能與 Master 保持一致，如下圖所示：
主從復(fù)制的方式和工作原理
Redis 的主從復(fù)制是異步復(fù)制，異步分為兩個(gè)方面：
- 一個(gè)是 Master 服務(wù)器在將數(shù)據(jù)同步到 Slave 時(shí)是異步的，因此 Master 服務(wù)器在這里仍然可以接收其他請(qǐng)求。
- 一個(gè)是 Slave 在接收同步數(shù)據(jù)也是異步的。
①復(fù)制方式
Redis 主從復(fù)制分為以下三種方式：
- 當(dāng) Master 服務(wù)器與 Slave 服務(wù)器正常連接時(shí)，Master 服務(wù)器會(huì)發(fā)送數(shù)據(jù)命令流給 Slave 服務(wù)器，將自身數(shù)據(jù)的改變復(fù)制到 Slave 服務(wù)器。
- 當(dāng)因?yàn)楦鞣N原因 Master 服務(wù)器與 Slave 服務(wù)器斷開后，Slave 服務(wù)器在重新連上 Master 服務(wù)器時(shí)會(huì)嘗試重新獲取斷開后未同步的數(shù)據(jù)即部分同步，或者稱為部分復(fù)制。
- 如果無法部分同步(比如初次同步)，則會(huì)請(qǐng)求進(jìn)行全量同步，這時(shí) Master 服務(wù)器會(huì)將自己的 RDB 文件發(fā)送給 Slave 服務(wù)器進(jìn)行數(shù)據(jù)同步，并記錄同步期間的其他寫入，再發(fā)送給 Slave 服務(wù)器，以達(dá)到完全同步的目的，這種方式稱為全量復(fù)制。
②工作原理
Master 服務(wù)器會(huì)記錄一個(gè) Replication Id 的偽隨機(jī)字符串，用于標(biāo)識(shí)當(dāng)前的數(shù)據(jù)集版本，還會(huì)記錄一個(gè)當(dāng)數(shù)據(jù)集的偏移量 Offset。
不管 Master 是否有配置 Slave 服務(wù)器，Replication Id 和 Offset 會(huì)一直記錄并成對(duì)存在，我們可以通過以下命令查看 Replication Id和 Offset：
> info repliaction
通過 redis-cli 在 Master 或 Slave 服務(wù)器執(zhí)行該命令會(huì)打印類似以下信息(不同服務(wù)器數(shù)據(jù)不同，打印信息不同)：
connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1 master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee master_repl_offset:9472
當(dāng) Master 與 Slave 正常連接時(shí)，Slave 使用 PSYNC 命令向 Master 發(fā)送自己記錄的舊 Master 的 Replication id 和 Offset。
而 Master 會(huì)計(jì)算與 Slave 之間的數(shù)據(jù)偏移量，并將緩沖區(qū)中的偏移數(shù)量同步到 Slave，此時(shí) Master 和 Slave 的數(shù)據(jù)一致。
而如果 Slave 引用的 Replication 太舊了，Master 與 Slave 之間的數(shù)據(jù)差異太大，則 Master 與 Slave 之間會(huì)使用全量復(fù)制的進(jìn)行數(shù)據(jù)同步。
配置主從復(fù)制
Redis 的主從配置非常簡(jiǎn)單，我們可以使用兩種方式來配置主從服務(wù)器，在這時(shí)我們先假設(shè) Redis 的 Master 服務(wù)器地址為 192.168.0.101。
客戶端發(fā)送同步命令：
# 向客戶端 saveof 192.168.1.101 6379
Slave 服務(wù)器配置主服務(wù)器：在這里 Slave 服務(wù)器的 redis.conf 通過 saveof 選項(xiàng)，可以指定 Master 服務(wù)器，如下：
slaveof 192.168.1.101 6379
通過上面兩種方式的配置，Master 服務(wù)器與 Slave 服務(wù)器便已經(jīng)可以開始進(jìn)行數(shù)據(jù)同步了。
Master 要求驗(yàn)證：上面配置的是 Master 服務(wù)器沒有設(shè)置密碼的情況，如果 Master 設(shè)置了密碼，則可以在連接到 Slave 服務(wù)器的 redis-cli 執(zhí)行下面的命令：
# <password>指代實(shí)際的密碼 config set masterauth <password>
或者在 Slave 服務(wù)器的 redis.conf 中配置下面的選項(xiàng)：
# <password>指代實(shí)際的密碼 masterauth <password>
避免 Slave 被清空
Slave 會(huì)被清空?Slave 不用同步了 Master 的數(shù)據(jù)嗎?備份的數(shù)據(jù)怎么會(huì)清空了呢?
當(dāng) Master 服務(wù)器關(guān)閉了持久化時(shí)，如果發(fā)生故障后自動(dòng)重啟時(shí)，由本地沒有保存持久化的數(shù)據(jù)，重啟的 Redis 內(nèi)存數(shù)據(jù)為空，而 Slave 會(huì)自動(dòng)同步 Master 的數(shù)據(jù)，這時(shí)候，Slave 服務(wù)器的數(shù)據(jù)也會(huì)被清空。
如何避免 Slave 被清空呢?如果條件允許(一般都可以的)，Master 服務(wù)器還是要開啟持久化，這樣 Master 故障重啟時(shí)，可以快速恢復(fù)數(shù)據(jù)，而同步這臺(tái) Master 的 Slave 數(shù)據(jù)也不會(huì)被清空。
如果 Master 不能開啟持久化，則不應(yīng)該設(shè)置讓 Master 發(fā)生故障后重啟(有些機(jī)器會(huì)配置自動(dòng)重啟)，而是將某個(gè) Slave 服務(wù)器升級(jí)為 Master 服務(wù)器，對(duì)外繼續(xù)提供服務(wù)。
Slave 默認(rèn)為只讀的
在 Redis 2.6 以后，Slave 只讀模式是默認(rèn)開啟的，我們可以通過配置文件中的 slave-read-only 選項(xiàng)配置是否開啟只讀模式：
# 默認(rèn)是yes slave-read-only yes/no
或者在客戶端中通過 config set 命令設(shè)置是否開啟只讀模式：
config set slave-read-only no
上面將 Slave 服務(wù)器設(shè)置為可以寫入，但是要注意，如果 Slave 也配置了自己的從服務(wù)器(Sub-Slave)，那么 Sub-Slave 只會(huì)同步從 Master 服務(wù)器同步到 Slave 的數(shù)據(jù)，而并會(huì)同步我們直接寫入 Slave 服務(wù)器的數(shù)據(jù)。
主從復(fù)制中的 Key 過期問題
我們都知道 Redis 可以通過設(shè)置 Key 的過期時(shí)間來限制 Key 的生存時(shí)間，Redis 處理 Key 過期有惰性刪除和定期刪除兩種機(jī)制。
而在配置主從復(fù)制后，Slave 服務(wù)器就沒有權(quán)限處理過期的 Key，這樣的話，對(duì)于在 Master 上過期的 Key，在 Slave 服務(wù)器就可能被讀取。
所以 Master 會(huì)累積過期的 Key，積累一定的量之后，發(fā)送 Del 命令到 Slave，刪除 Slave 上的 Key。
如果 Slave 服務(wù)器升級(jí)為 Master 服務(wù)器 ，則它將開始獨(dú)立地計(jì)算 Key 過期時(shí)間，而不需要通過 Master 服務(wù)器的幫助。
主從復(fù)制的作用
①保存 Redis 數(shù)據(jù)副本
當(dāng)我們只是通過 RDB 或 AOF 把 Redis 的內(nèi)存數(shù)據(jù)持久化畢竟只是在本地，并不能保證絕對(duì)的安全，而通過將數(shù)據(jù)同步 Slave 服務(wù)器上，可以保留多一個(gè)數(shù)據(jù)備份，更好地保證數(shù)據(jù)的安全。
②讀寫分離
在配置了主從復(fù)制之后，如果 Master 服務(wù)器的讀寫壓力太大，可以進(jìn)行讀寫分離，客戶端向 Master 服務(wù)器寫入數(shù)據(jù)，在讀數(shù)據(jù)時(shí)，則訪問 Slave 服務(wù)器，從而減輕 Master 服務(wù)器的訪問壓力。
③高可用性與故障轉(zhuǎn)移
服務(wù)器的高可用性是指服務(wù)器能提供 7*24 小時(shí)不間斷的服務(wù)，Redis 可以通過 Sentinel 系統(tǒng)管理多個(gè) Redis 服務(wù)器。
當(dāng) Master 服務(wù)器發(fā)生故障時(shí)，Sentineal 系統(tǒng)會(huì)根據(jù)一定的規(guī)則將某臺(tái) Slave 服務(wù)器升級(jí)為 Master 服務(wù)器，繼續(xù)提供服務(wù)，實(shí)現(xiàn)故障轉(zhuǎn)移，保證 Redis 服務(wù)不間斷。
小結(jié)：Redis 的主從復(fù)制可以讓我們把 Redis 中的數(shù)據(jù)同步到其他服務(wù)器上，為數(shù)據(jù)安全提供更加安全的保障，也可以讓我們的服務(wù)器在發(fā)生故障而無法重啟時(shí)，可以更加快速地切換服務(wù)器，繼續(xù)對(duì)外提供服務(wù)。
