【Redis】Redis 的主從同步

很多企業都沒有使用 Redis 的集群，但是至少都做了主從。有了主從，當主節點(Master) 掛掉的時候，運維讓從節點 (Slave) 過來接管，服務就可以繼續，否則主節點需要經過數據恢復和重啟的過程，這就可能會拖延很長的時間，從而影響線上業務的持續服務。

盡管 Redis 的性能很好，但是有時候依舊滿足不了應用的需要，比如過多的用戶進入主頁.導致 Redis 被頻繁訪問，此時就存在大量的讀操作。在一些熱門網站，某個時刻(比如促銷商品的時候)有每秒成千上萬的請求是司空見慣的，這個時候大量的讀操作會到達 Redis 服務器.觸發許許多多的操作，顯然靠一臺 Redis 服務器是完全不夠用的。一些服務網站對安全性有較高的要求，當主服務器不能正常工作時，需要從服務器代替原來的主服務器作為災備，以保證系統可以繼續正常工作。因此更多的時候我們希望可以讀/寫分離，讀/寫分離的前提是讀操作遠遠比寫操作頻繁得多，如果把數據存放在多臺服務器上，就可以從多臺服務器中讀取數據,從而減輕單臺服務器的壓力了，讀/寫分離的技術已經廣泛用于數據庫中。

? 在了解 Redis 的主從復制之前，讓我們先來理解一下現代分布式系統的理論基石——CAP 原理。

CAP 原理

CAP 原理就好比分布式領域的牛頓定律，它是分布式存儲的理論基石。自從CAP的論文發表之后，分布式存儲中間件猶如雨后春筍般涌現出來。理解這個原理其實很簡單，本節我們首先對這個原理進行簡單的講解。

• C：Consistent，一致性
• A：Availability，可用性
• P：Partition tolerance ，分區容忍性

分布式系統的節點往往都是分布在不同的機器上進行網絡隔離開的，這意味著必然會有網絡斷開的風險，這個網絡斷開的場景的專業詞匯叫作網絡分區。

如下圖所示，在網絡分區發生時，兩個分布式節點之間無法進行通信，我們對一個節點進行的修改操作將無法同步到另外一個節點，所以數據的一致性將無法滿足，因為兩個分布式節點的數據不再保持一致。除非我們犧牲可用性，也就是暫停分布式節點服務，在網絡分區發生時，不再提供修改數據的功能，直到網絡狀況
完全恢復正常再繼續對外提供服務。

用一句話概括 CAP 原理就是: 當網絡分區發生時，一致性和可用性兩難全

最終一致

Redis的主從數據是異步同步的，所以分布式的 Redis系統并不滿足一致性要求當客戶端在 Redis的主節點修改了數據后，立即返回，即使在主從網絡斷開的情況下主節點依舊可以正常對外提供修改服務，所以 Redis 滿足可用性。

Redis 保證最終一致性，從節點會努力追趕主節點，最終從節點的狀態會和主節點的狀態保持一致。如果網絡斷開了，主從節點的數據將會出現大量不一致，但一旦網絡恢復，從節點會采用多種策略努力追趕，繼續盡力保持和主節點一致。

主從同步與從從同步

Redis 同步支持主從同步和從從同步，從從同步功能是 Redis 后續版本增加的功能，以減輕主節點的同步負擔。后面為了描述上的方便，統一理解為主從同步。

增量同步

Redis 同步的是指令流，主節點會將那些對自己的狀態產生修改性影響的指令錄在本地的內存 buffer 中，然后異步將 bufer 中的指令同步到從節點，從節點一邊執行同步的指令流來達到和主節點一樣的狀態，一邊向主節點反饋自己同步到哪里了(偏移量)。

? 因為內存的 buffer 是有限的，所以 Redis 主節點不能將所有的指令都記錄在內存 buffer 中。Redis 的復制內存 buffer是一個定長的環形數組，如圖所示，如果數組內容滿了，就會從頭開始覆蓋前面的內容。

? 如果因為網絡狀況不好，從節點在短時間內無法和主節點進行同步，那么當網絡狀況恢復時，Redis 的主節點中那些沒有同步的指令在buffer 中有可能已經被后續的指令覆蓋掉了，從節點將無法直接通過指令流來進行同步，這個時候就需要用到更加復雜的同步機制一一快照同步。

快照同步

? 快照同步是一個非常耗費資源的操作，如圖所示，它首先需要在主節點上進行一次 bgsave，將當前內存的數據全部快照到磁盤文件中，然后再將快照文件的內容全部傳送到從節點。從節點將快照文件接受完畢后，立即執行一次全量加載,加載之前先要將當前內存的數據清空，加載完畢后通知主節點繼續進行增量同步。

? 在整個快照同步進行的過程中，主節點的復制 buffer 還在不停地往前移動，如果快照同步的時間過長或者復制 buffer 太小，都會導致同步期間的增量指令在復制 buffer 中被覆蓋，這樣就會導致快照同步完成后無法進行增量復制，然后會再次發起快照同步，如此極有可能會陷入快照同步的死循環。所以務必配置一個合適的復制 buffer 大小參數，避免快照復制的死循環。

Redis 主從同步基礎概念

互聯網系統一般以主從架構為基礎，所謂主從架構設計的思路大概如下。

• 在多臺數據服務器中，只有一臺主服務器，而主服務器只負責寫入數據，不負責讓外部程序讀取數據。
• 存在多臺從服務器，從服務器不寫入數據，只負責同步主服務器的數據，并讓外部程序讀取數據。
• 主服務器在寫入數據后，即刻將寫入數據的命令發送給從服務器，從而使得主從數據同先。
• 應用程序可以隨機讀取某一臺從服務器的數據，這樣就分攤了讀數據的壓力。
• 當從服務器不能工作的時候，整個系統將不受影響;當主服務器不能工作的時候，可以方便地從從服務器中選取一臺來當主服務器。

請注意上面的思路，我用了“大概”這兩個字，因為這只是一種大概的思路，每一種數據存儲軟件都會根據其自身的特點對上面的這幾點思路加以改造，但是萬變不離其宗，只要理解了這幾點就很好理解 Redis 的復制機制。主從同步機制如下圖所示。

這個時候讀數據可以隨機從從服務器上讀取，當從服務器是多臺的時候，單臺服務器的壓力就大大降低了，這十分有利于系統性能的提高，當主服務器出現不能工作的情況時，也可以切換為其中的一臺從服務器繼續讓系統穩定運行，所以也有利于系統運行的安全。當然，由于Redis 自身具備的特點，所以其也有實現主從同步的特殊方式。

首先，明確主機，我們將從主機復制數據發往從機：其次，明確從機。有了這兩點后，就可以進行進一步配置了;再次，看 redis.conf 文件，這里要關注的只有 replicaof這個配置選項,它的配置格式是:

replicaof <masterip> <masterport>

其中，masterip 代表主機，masterport 代表端口。當從機 Redis 服務重啟時，就會同步主機的數據。當不想讓從機繼續復制主機的數據時，可以在從機執行命令

replicaof no one

這樣從機就不會再接收主機更新的數據了。又或者原來的主機已經無法工作了，需要復制新的主機，這個時候執行

replicaof <masterip> <masterport>

就能讓從機復制另外一臺主機的數據了。

在實際的 Linux 環境中，配置文件 redis.conf中還有一個bind 的配置，默認為127.0.0.1也就是只允許本機訪問，這里需要修改它，將其配置為0.0.0.0，這樣其他的服務器就能夠訪問了。

Redis 主從同步的過程

Redis 主從同步的過程如下圖所示。

上圖中左邊的流程是主服務器，右邊的流程是從服務器，這里有必要進行更深層次的描述。

(1)無論如何要先保證主服務器開啟，開啟主服務器后，從服務器通過命令或者重啟配置項可以同步到主服務器。

(2)當從服務器啟動時，讀取同步的配置，根據配置決定是否使用當前數據響應客戶端,然后發送SYNC命令。當主服務器接收到同步命令時，就會執行 bgsave 命令備份數據，但是主服務器并不會拒絕客戶端的讀/寫，而是將來自客戶端的寫命令寫入緩沖區。從服務器未收到主服務器備份的快照文件時，會根據其配置決定使用現有數據響應或者拒絕客戶端請求。

(3)當bgsave 命令被主服務器執行完后，開始向從服務器發送備份文件，這個時候從服務器就會丟棄所有現有的數據，開始載入主服務器發送的快照文件。

(4)當主服務器發送完備份文件后，從服務器就會執行這些寫入命令。此時就會把 bgsave執行之后的緩存區內的寫命令也發送給從服務器，從服務完成備份文件解析，就開始像往常-樣，接收命令，等待命令寫入。

(5)緩沖區的命令發送完成后，主服務器執行完一條寫命令，就向從服務器發送同步寫入命令，從服務器就和主服務器保持一致了。而此時當從服務器完成主服務器發送的緩沖區命令后，就開始等待主服務器的命令了。

以上5步就是 Redis 主從同步的過程。

**在主服務器同步到從服務器的過程中，需要備份文件，所以在配置的時候一般需要預留-些內存空間給主服務器，用以執行備份命令。**一般來說主服務器使用 50%~65%的內存空間，以為主從復制留下可用的內存空間。

多從機同步機制，如下圖所示。

如果出現多臺同步，那么可能出現頻繁等待和操作 bgsave 命令的情況，導致主機在較長時間里性能不佳，這個時候我們會考慮主從鏈同步的機制，以減少這種可能。

不過復制功能也不是必需的，如果你只用 Redis做緩存，跟 memcache 一樣對待也就不需要從節點做備份，掛掉了重新啟動一下就行。但是只要你使用了 Redis 的持久化功能，就必須認真對待主從復制，它是系統數據安全的基礎保障。