在分布式系統中為了解決單點問題（某個服務器程序只有一個節點（只搞一個物理服務器來部署這個服務器程序）。可用性不高：如果這個機器掛了意味著服務就中斷了；性能 / 支持的并發量比較有限）。通常會把數據復制多個副本部署到其他服務器，滿足故障恢復和負載均衡等需求。在分布式系統中，往往希望有多個服務器來部署 Redis 服務，從而構成一個 Redis 集群，此時就可以讓這個集群給整個分布式系統中的其他服務提供更穩定、更高效的數據存儲功能。存在以下幾種 Redis 的部署方式：

• 主從模式

在若干個 Redis 節點中，有的是 “主” 節點，有的是 “從” 節點。從節點上的數據要隨著主節點變化，和主節點保持一致。從節點是主節點的副本，在該模式中，從節點上的數據不允許修改，只能讀取數據。后續如果有客戶端來讀取數據，就可以從所有節點中隨機挑選一個節點，給這個客戶端提供讀取數據的服務。

引入更多的計算資源，那么能夠支撐的并發量也就大幅提高了。如果是掛掉了某個從節點是沒有什么影響的，此時繼續從主節點（如果是主節點掛掉了，那還是有一定影響的，從系欸但只能讀數據，如果需要寫數據就沒得寫了）或者其它的從節點讀取數據，得到的效果是完全相同的。

主從模式主要是針對 “讀操作” 進行并發量和可用性的提高，而寫操作無論是可用性還是并發都是非常依賴主節點的，但主節點又不能設置多個。在實際業務場景中，讀操作往往是比寫操作更頻繁的。

主從結構是分布式系統中比較經典的一種結構。不僅僅是 Redis 支持，MySQL 等其它的常用組件也是支持的。

主從復制的特點：

1. Redis 通過復制功能實現主節點的多個副本。
2. 主節點用來寫，從節點用來讀，這樣做可以降低主節點的訪問壓力。
3. 復制支持多種拓撲結構，可以在適當的場景選擇合適的拓撲結構。
4. 復制分為全量復制，部分復制和實時復制。
5. 主從節點之間通過心跳機制保證主從節點通信正常和數據?致性。

• 主從 + 哨兵模式
• 集群模式

Redis 為我們提供了復制的功能，實現了相同數據的多個 Redis 副本。復制功能是高可用?Redis 的基礎，哨兵和集群都是在復制的基礎上構建的。

一、配置

1、建立復制

如何在一個云服務器上實現分布式呢？

? ? 可以在一個云服務器主機上運行多個 redis-server 進程，此處需要保證多個 redis-server 的端口是不相同的。例如：本來 redis-server 默認的端口是 6379，此時就不能讓新啟動的 redis-server 再繼續使用 6379 了。? ? ?

如何去指定 redis-server 的端口呢？

• 可以在啟動程序時，通過命令行來指定端口號，--port 選項。
• 也可以直接在配置文件中來設定端口。（推薦，更方便）?

將 redis.conf 配置文件復制兩份：slave1.conf 和 slave2.conf（準備一個主節點和兩個從節點）。

注意：修改配置主要是修改從機的配置，主機配置不變。

接下來，通過命令行啟動上述兩個 Redis 實例作為從 Redis，并且通過 ps aux | grep redis 確保兩個 Redis 均已正確啟動：

當前這幾個節點并沒有構成主從結構，而是各自為政。要想成為主從結構，還需要進一步的進行配置。

通過 redis-cli 可以連接主 Redis 實例，通過 redis-cli -p 6380 連接從 Redis，并且觀察復制關系。

參與復制的 Redis 實例劃分為主節點（master）和從節點（slave）。每個從節點只能有?個主節點，而一個主節點可以同時具有多個從節點。復制的數據流是單向的，只能由主節點到從節點。配置復制的方式有以下三種：

1. 在配置文件中加入 slaveof {masterHost} {masterPort} 隨 Redis 啟動生效（推薦，持久生效）。
2. 在 redis-server 啟動命令時加入 --slaveof {masterHost} {masterPort} 生效。
3. 直接使用 redis 命令：slaveof {masterHost} {masterPort} 生效。

此處以 6379 為主節點，6380 和 6381 為從節點。

在 slave1.conf 末尾添加：

在 slave2.conf 末尾添加：

Redis?服務器的配置文件修改之后需要重新啟動才能生效：

上述通過 kill -9 進程的方式來停止 redis-server 是和我們之前通過直接運行 redis-server 命令的方式搭配使用的。而如果是使用 service redis-server start 這種方式啟動的，就必須使用 service redis-server stop 來進行停止。（此時如果使用 kill -9 的方式停止，那么在 kill 掉之后，這個 redis-server 進程還能自動啟動）。

服務器就是要穩定性和高可用，但是服務器上的某些程序也難以避免出現掛了的情況。如果服務進程掛了，要是能自動重啟進程，對于整體的服務不會產生嚴重影響。

可以看到，相比之前多了一些進程，其中多出來的這些進程用來表示 Redis 從節點和主節點之間的 tcp 連接（從節點啟動后就會和主節點建立上 tcp 連接），主節點就相當于服務器，從節點就相當于客戶端。

從運行結果中看到復制已經工作了，針對主節點 6379 這邊數據產生的任何修改，從節點都能立即感知到并同步，就是前面看到的那些 tcp 連接產生的效果。其次，從節點不能寫入數據。

Redis 主從節點復制過程：

可以通過 info replication 命令查看復制相關狀態：

• 主節點 6379 復制狀態信息：

主節點上會收到源源不斷地 “修改數據” 請求，從節點就需要從主節點這里同步這些修改請求。從節點和主節點之間的數據同步不是瞬間完成的，上面的 offset 就相當于是從節點和主節點之間同步數據的進度，lag 表示延遲情況。

• 從節點 6380 復制狀態信息：

repl_backlog：擠壓緩沖區，支持部分同步機制的實現。

2、斷開復制

slaveof 命令不但可以建立復制，還可以在從節點執行?slaveof no one?來斷開與主節點復制關系。例如：在 6380 節點上執行?slaveof no one 來斷開復制。

（1）斷開復制主要流程

1. 斷開與主節點復制關系。
2. 從節點晉升為主節點。

從節點斷開復制后，它就不再從屬于其它節點了，也并不會拋棄原有數據，后續主節點如果針對數據做出修改，從節點無法再自動獲取主節點上的數據變化。

通過 slaveof 命令還可以實現切主操作，將當前從節點的數據源切換到另?個主節點。執行 slaveof {newMasterIp} {newMasterPort} 命令即可。

（2）切主操作主要流程

1. 斷開與舊主節點復制關系。
2. 與新主節點建立復制關系。
3. 刪除從節點當前所有數據。
4. 從新主節點行復制操作。

此時的 6381 只是看起來像是個主節點，但實際上并不是，它仍然是個從節點，只是作為 6380 同步數據的來源，自身仍然是不能修改數據的。

注意：前面是通過 salveof 修改了主從結構，這個修改時臨時性的。如果重新啟動 Redis 服務器，仍然會按照最初在配置文件中設置的內容來建立主從關系。

3、安全性

對于數據比較重要的節點，主節點會通過設置 requirepass 參數進行密碼驗證，這時所有的客戶端訪問必須使用 auth 命令實行校驗。從節點與主節點的復制連接是通過?個特殊標識的客戶端來完成，因此需要配置從節點的 masterauth 參數與主節點密碼保持一致，這樣從節點才可以正確地連接到主節點并發起復制流程。

4、只讀

默認情況下，從節點使用?slave-read-only=yes?配置為只讀模式。由于復制只能從主節點到從節點，對于從節點的任何修改主節點都無法感知，修改從節點會造成主從數據不?致，所以建議線上不要修改從節點的只讀模式。

5、傳輸延遲
主節點和從節點之間通過網絡來傳輸（TCP），TCP 內部支持 nagle 算法（默認開啟），開啟后就會增加 tcp 的傳輸延遲，節省網絡帶寬；關閉就會減少 tcp 的傳輸延遲，增加網絡帶寬，從節點能夠更快速的和主節點進行同步。其目的和 tcp 的捎帶應答是一樣的，針對小的 tcp 數據報進行合并，減少包的個數。主從節點一般部署在不同機器上，復制時的網絡延遲就成為需要考慮的問題，Redis 提供了 repl-disable-tcp-nodelay 參數用來控制是否關閉 TCP_NODELAY（在主從同步通信過程中是否關閉 tcp 的 nagle 算法），默認為 no，即開啟 tcp-nodelay 功能，說明如下：

• 當關閉時，主節點產生的命令數據無論大小都會及時地發送給從節點，這樣主從之間延遲會變小，但增加了網絡帶寬的消耗，適用于主從之間的網絡環境良好的場景，如同機房部署。
• 當開啟時，主節點會合并較小的 TCP 數據包從而節省帶寬。默認發送時間間隔取決于 Linux 的內核，一般默認為 40 毫秒。這種配置節省了帶寬但增大主從之間的延遲，適用于主從?絡環境復雜的場景，如跨機房部署。

二、拓撲

Redis 的復制拓撲結構可以支持單層或多層復制關系，根據拓撲復雜性可以分為以下三種：一主一從、一主多從、樹狀主從結構。

1、一主一從結構

一主一從結構是最簡單的復制拓撲結構，用于主節點出現宕機時從節點提供故障轉移支持，如圖所示。

一主一從拓撲：

當應用寫命令并發量較高且需要持久化時，此時也是會給主節點造成一些壓力，那么可以只在從節點上開啟 AOF，這樣既可以保證數據安全性同時也避免了持久化對主節點的性能干擾。但需要注意的是，這種設定方式有一個嚴重的缺陷：當主節點關閉持久化功能時，如果主節點宕機要避免自動重啟操作，否則就會丟失數據，進一步的主從同步，也會把從節點的數據也給刪了。

改進辦法：當主節點掛了之后，需要讓主節點從從節點這里獲取到 AOF 的文件，再重新啟動。

2、一主多從結構

在實際開發中，讀請求往往遠超過寫請求，所以一般會選擇一主多從結構。一主多從結構（星形結構）使得應用端可以利?多個從節點實現讀寫分離，如下圖所示。

一主多從拓撲：

主節點上的數據發生改變時，就會把改變的數據同時同步給所有的從節點。對于讀比重較大的場景，可以把讀命令負載均衡到不同的從節點上來分擔壓力。同時一些耗時的讀命令可以指定一臺專門的從節點執行，避免破壞整體的穩定性。對于寫并發量較高的場景，多個從節點會導致主節點寫命令的多次發送從而加重主節點的負載。

3、?樹形主從結構

樹形主從結構（分層結構）使得從節點不但可以復制主節點數據，同時可以作為其他從節點的主節點繼續向下層復制。通過引?復制中間層，可以有效降低住系欸按負載和需要傳送給從節點的數據量，如下圖所示。

數據寫如節點 A 之后會同步給 B 和 C 節點，B 節點進一步把數據同步給 D 和 E 節點。當主節點需要掛載等多個從節點時為了避免對主節點的性能干擾，可以采用這種拓撲結構。此時，主節點就不需要很高的網卡帶寬了，但一旦數據進行修改，同步的延時是比之前的結構更長的。

三、原理

1、復制過程

如下圖所示，詳細介紹建立復制的完整流程。從圖中可以看出復制過程?致分為 6 個過程：

主從節點建立復制流程圖：

1）保存主節點（master）的信息

開始配置主從同步關系之后，從節點只保存主節點的地址信息，此時建立復制流程還沒有開始，在從節點 6380 執行?info replication 可以看到如下信息：

從統計信息可以看出，主節點的 ip 和 port 被保存下來，但是主節點的連接狀態（master_link_status）是下線狀態。

---

（2）從節點（slave）內部通過每秒運行的定時任務維護復制相關邏輯

當定時任務發現存在新的主節點后，會嘗試與主節點建立基于 TCP 的網絡連接（三次握手，是為了驗證（系統層面）通信雙方是否能夠正確讀寫數據）。如果從節點無法建立連接，定時任務會無限重試直到連接成功或者用戶停止主從復制。

（3）發送 ping 命令

連接建立成功之后，從節點通過 ping 命令確認主節點在應用層上是否能夠正常工作。如果 ping 命令的結果 pong 回復超時，從節點會斷開 TCP 連接，等待定時任務下次重新建立連接。

（4）權限驗證

如果主節點設置了 requirepass 參數，則需要密碼驗證，從節點通過配置 masterauth 參數來設置密碼。如果驗證失敗，則從節點的復制將會停止。

（5）同步數據集

對于首次建立復制的場景，主節點會把當前持有的所有數據全部發送給從節點，這步操作基本是耗時最長的，所以又劃分稱兩種情況：全量同步和部分同步。

（6）命令持續復制

當從節點復制了主節點的所有數據之后，針對之后的修改命令，主節點會持續的把命令發送給從節點，從節點執行修改命令，保證主從數據的一致性。

2、數據同步 psync

Redis 使用?psync?命令（不需要手動執行，Redis 服務器會在建立好主從同步關系之后自動執行。從節點負責執行 psync，從節點從主節點這邊拉取數據）完成主從數據同步，同步過程分為：全量復制和部分復制。

• 全量復制：一般用于初次復制場景，Redis 早期支持的復制功能只有全量復制，它會把主節點全部數據一次性發送給從節點，當數據量較大時，會對主從節點和網絡造成很大的開銷。
• 部分復制：用于處理在主從復制中因網絡閃斷等原因造成的數據丟失場景，當從節點再次連上主節點后，如果條件允許，主節點會補發數據給從節點。因為補發的數據遠小于全量數據，可以有效避免全量復制的過高開銷。

（1）PSYNC 的語法格式??

PSYNC replicationid offset

• 如果 replicationid 設為 ? 并且 offset 設為 -1，就是在嘗試進行全量復制。
• 如果 replicationid offset 設為了具體的數值，則是嘗試進行部分復制。?

A.??replicationid / replid（復制 id）

主節點的復制 id。主節點重新啟動或者從節點晉級成主節點都會生成?個?replicationid（同一個節點每次重啟生成的 replicationid 都是不同的）

?

從節點在和主節點建立復制關系之后，就會獲取到主節點的 replicationid。

通過?info replication?即可看到 replicationid：

? a.?replication id VS run id

在一個 Redis 服務器上，replication id 和 run id 都是存在的，兩個不同的 id 看起來非常像。

??

可以看出，每個節點的 run id 都不相同，而具有主從關系的節點的 replid 是相同的。

官方文檔明確所里，此處使用的是 replicationid：

eplid + offset 共同標識了一個數據集合。

下面這個結構體包含了 Redis 服務器的各自重要數據：

標識一次 Redis 的 “運行”：

runid 主要是用在支撐實現 Redis 哨兵這個功能的，和主從復制沒有什么關系。

b. 關于 master_replid 和 master_replid2
通過上圖，我們可以看到每個節點需要記錄兩組 master_replid，這個設定解決的問題場景是這樣的：

假設有一個主節點 A 和一個從節點 B，從節點 B 獲取到 A 的 replid。如果 A 和 B 在通信過程中出現了一些網絡抖動，那么 B 可能就會以為 A 掛了，B 自己就會成為主節點，于是 B 給自己生成一個 master_replid。此時 B 也會記得之前舊的 replid，也就是會使用 master_replid2 來保存之前 A 的 master_replid。

• 后續如果網絡恢復穩定了，B 就可以根據 master_replid2 找回之前的主節點。（該過程要么手動干預，要么通過哨兵機制可以自動完成這個過程）
• 后續如果網絡沒有恢復，B 就按照新的 master_replid 自成一派，繼續處理后續的數據。

B.?offset（偏移量）

參與復制的主從節點都會維護自身復制偏移量（整數）。主節點（master）在處理完寫入命令后，會把命令的字節長度做累加記錄，統計信息在 info replication 中的 master_repl_offset 指標中。

從節點（slave）每秒鐘上報自身的復制偏移量給主節點，因此主節點也會保存從節點的復制偏移量，統計指標如下：

從節點在接受到主節點發送的命令后，也會累加記錄自身的偏移量。統計信息在 info replication 中的 slave_repl_offset 指標中：

---

復制偏移量的維護如圖所示。通過對比主從節點的復制偏移量，可以判斷主從節點數據是否一致。

a. 復制偏移量維護

replid + offset 共同標識了?個 “數據集”。如果兩個節點，他們的 replid 和 offset 都相同，則這兩個節點上持有的數據，就一定相同。

b.?psync 運行流程

1. 從節點發送 psync 命令給主節點，replid 和 offset 的默認值分別是 ? 和 -1。
2. 并不是說從節點索要哪一部分，主節點就一定給哪一部分，而是主節點根據 psync 參數和自身數據情況決定響應結果：

• 如果回復 +FULLRESYNC replid offset，則從節點需要進行全量復制流程。
• 如果回復 +CONTINEU，從節點進行部分復制流程。
• 如果回復 -ERR，說明 Redis 主節點版本過低，不?持 psync 命令（可以使用 sync 代替）。從節點可以使用 sync 命令進行全量復制。
• psync ?般不需要手動執行，Redis 會在主從復制模式下自動調用執行。
• sync 會阻塞 redis server 處理其他請求，psync 則不會。

3、全量復制

全量復制是 Redis 最早支持的復制方式，也是主從第一次建立復制時必須經歷的階段。全量復制的運行流程如下圖所示。

什么時候進行全量復制？

• 首次和主節點進行數據同步。
• 主節點不方便進行部分復制的時候。

1）全量復制的流程

1. 從節點發送 psync 命令給主節點進行數據同步，由于是第?次進行復制，從節點沒有主節點的運行 ID 和復制偏移量，所以發送 psync ? -1。
2. 主節點根據命令，解析出要進行全量復制，回復 +FULLRESYNC 響應。
3. 從節點接收主節點的運行信息進行保存。
4. 主節點執行 bgsave 進行 RDB 文件的持久化。（不能使用已有的 RDB 文件，而是必須要重新生成一下，因為已有的 RDB 文件可能會和當前最新的數據存在較大差異）
5. 主節點發送 RDB 文件給從節點，從節點保存 RDB 數據到本地硬盤。（RDB 文件更節省空間）
6. 主節點將從生成 RDB 到接收完成期間執行的寫命令寫入緩沖區中，等從節點保存完 RDB 文件后，主節點再將緩沖區內的數據補發給從節點，補發的數據仍然按照 RDB 的二進制格式追加寫入到收到的 RDB 文件中，保持主從一致性。
7. 從節點清空自身原有舊數據。
8. 從節點加載 RDB 文件得到與主節點一致的數據。
9. 如果從節點加載 RDB 完成之后，并且開啟了 AOF 持久化功能，那么在前面加載數據的過程中，從節點就會產生出很多的 AOF 日志。由于當前收到的是大批量的數據，此時產生的 AOF 日志可能會存在一定的冗余信息，因此針對 AOF 日志進行 bgrewrite 操作，得到最近的 AOF 文件也是必要的過程。

通過分析全量復制的所有流程，會發現全量復制是一件高成本的操作：主節點 bgsave 的時間，RDB 在網絡傳輸的時間，從節點清空舊數據的時間，從節點加載 RDB 的時間等。所以一般應該盡可能避免對已經有大量數據集的 Redis 進行全量復制。

A. 有磁盤復制 VS?無磁盤復制（diskless）

默認情況下，進行全量復制需要主節點生成 RDB 文件到主節點的磁盤中，再把磁盤上的 RDB 文件通過發送給從節點。

Redis 從 2.8.18 版本開始支持無磁盤復制。主節點在執行 RDB 生成流程時，不會生成 RDB 文件到磁盤中了，而是直接把生成的 RDB 數據通過網絡發送給從節點，這樣就節省了?系列的寫硬盤和讀硬盤的操作開銷。

從節點之前也是先把收到的 RDB 數據寫入到硬盤中，再進行加載。現在也可以省略這個過程，直接把收到的數據進行加載了。

但是即使引入了無硬盤模式，整個操作仍然是比較重量、耗時的，網絡傳輸（大規模數據全量復制）的過程是沒有辦法省的。相比于網絡傳輸來說，讀寫硬盤的開銷是很小的。

4、部分復制

什么時候進行部分復制？

從節點之前已經從主節點上復制過數據了。因為網絡抖動或者從節點重啟了，從節點需要重新從主節點這邊同步數據，此時看看能不能只同步一小部分（大部分數據都是一致的）。?

部分復制主要是 Redis 針對全量復制的過高開銷做出的一種優化措施，使用 psync replicationId offset 命令實現。當從節點正在復制主節點時，如果出現網絡閃斷或者命令丟失等異常情況時，從節點會向主節點要求補發丟失的命令數據，如果主節點的復制積壓緩沖區存在數據則直接發送給從節點，這樣就可以保持主從節點復制的一致性。補發的這部分數據一般遠遠小于全量數據，所以開銷很小。整體流程如下圖所示。

1. 當主從節點之間出現網絡中斷時，如果超過 repl-timeout 時間，主節點會認為從節點故障并終端復制連接。
2. 主從連接中斷期間主節點依然響應命令，但這些復制命令都因網絡中斷無法及時發送給從節點，所以暫時將這些命令滯留在復制積壓緩沖區（一個內存中簡單的隊列，會記錄最近一段時間修改的數據，因為總量有限，隨著時間推移就會把之前舊的數據逐漸刪除）中。
3. 當主從節點網絡恢復后，從節點再次連上主節點。
4. 從節點將之前保存的 replicationId（描述 “數據的來源”）和 復制偏移量（offset，描述 “數據復制的進度”，主節點看這個進度來判斷它是否在當前的積壓緩沖區內，如果是則可以直接進行部分復制）作為 psync 的參數發送給主節點，請求進行部分復制。
5. 主節點接到 psync 請求后，進行必要的驗證。隨后根據 offset 去復制積壓緩沖區查找合適的數據，并響應 +CONTINUE 給從節點。
6. 主節點將需要從節點同步的數據發送給從節點，最終完成一致性。

（1）復制積壓緩沖區

復制積壓緩沖區是保存在主節點上的一個固定長度的隊列，默認大小為 1MB，當主節點有連接的從節點（slave）時被創建，這時主節點（master）響應寫命令時，不但會把命令發送給從節點，還會寫入復制積壓緩沖區，如下圖所示。

由于緩沖區本質上是先進先出的定長隊列，所以能實現保存最近已復制數據的功能，用于部分復制和復制命令丟失的數據補救。復制緩沖區相關統計信息可以通過主節點的 info replication 中：

根據統計指標，可算出復制積壓緩沖區內的可用偏移量范圍：[repl_backlog_first_byte_offset, repl_backlog_first_byte_offset + repl_backlog_histlen]。

這個相當于一個基于數組實現的環形隊列，上述區間中的值就是 “數組下標”。

如果當前從節點需要的數據已經超出了主節點的積壓緩沖區的范圍，則無法進行部分復制，只能全量復制了。

5、實時復制

主從節點在建立復制連接后，主節點會把自己收到的修改操作，通過 tcp 長連接的方式，源源不斷的傳輸給從節點，從節點就會根據這些請求來同時修改自身的數據，從而保持和主節點數據的一致性。在進行實時復制的時候需要保證連接處于可用狀態，所以這樣的長連接需要通過心跳包的方式來維護連接狀態（這里的心跳是指應用層自己實現的心跳，而不是 TCP 自帶的心跳）。

1. 主從節點彼此都有心跳檢測機制，各自模擬成對方的客戶端進行通信。
2. 主節點默認每隔 10 秒對從節點發送 ping 命令，從節點收到就返回 pong，以此來判斷從節點的存活性和連接狀態。
3. 從節點默認每隔 1 秒向主節點發送一個?replconf ack {offset} 命令，給主節點上報自身當前的復制偏移量（offset，“進度”）。

四、補充

1、關于從節點何時晉升成主節點的問題

從節點和主節點之間斷開連接有兩種情況：

1. 從節點主動和主節點斷開連接：slaveof no one（此時，從節點就能夠晉升成主節點），意味著我們要主動修改 Redis 的組成結構。
2. 主節點掛了（此時，從節點不會晉升成主節點的，必須通過人工干預的方式來恢復主節點）。這種是脫離我們的掌控的，是一個高可用下的典型問題。

2、關于 redis 主節點無法重啟的問題

前面的 6379、6380、6381 這三個 redis server 用的是同一個 aof 文件（最開始創建從節點的配置的文件路徑都一樣，沒有進行修改）。

從節點是通過手動啟動的方式運行的，此時 root 用戶下啟動的 redis 服務器，于是生成的 aof 文件也就是 root 用戶的文件。

通過 service redis-server start 啟動的 redis 服務器是通過一個 redis 這樣的用戶來啟動的（所屬用戶是 redis 用戶），主要是擔心通過 root 啟動 redis 權限太高，一旦 redis 被黑客攻破，后果就比較嚴重了。所以，redis server 需要安裝可讀可寫的方式打開這個 aof 文件，而這個文件對于 root 之外的用戶只有讀權限。

解決方案：將這三個 Redis 服務器生成的文件給區分開，最靠譜的是：直接把這三個 Redis 的工作目錄給區分開（修改配置文件中的 dir 選項）。

停止之前的 Redis 服務器：

刪除之前工作目錄下已經生成的 aof 文件或者通過 chown 命令修改 aof 文件所屬的用戶：

給從節點創建出新的目錄，作為從節點的工作目錄：

并且修改從節點的配置文件，設定新的目錄為工作目錄：

啟動 redis 服務器：

從節點有了自己的 rdb 文件和 aof 文件：