圖文結合！一文搞懂Redis 主從複製做用及場景模式和原理！

目錄

1. 什麼是 Redis 主從複製
2. 主從複製的做用及場景
3. 主從複製的模式

• 一主一從
• 一主多從

4.主從複製的原理

• 全量複製
• 部分複製
• 總結

什麼是 Redis 主從複製

總所周知 Redis 之因此火由於它有着讀取速度快、可持久化的優勢。Redis 的持久化保證了斷電或重啓數據不會丟失。但僅僅這樣是不夠的，持久化是將數據按期寫入磁盤中，萬一哪一天這一臺服務器掛掉了，那全部數據依舊會丟失。爲了解決這個單點故障問題，因此就有了主從複製。

主從複製就是將一臺 Redis 服務器的數據自動地複製到其餘 Redis 服務器上。一臺服務器出故障的機率很高，可是多臺服務器同時出故障的機率就很低了吧。所謂主從主從，固然是有主服務器（Master）和從服務器（Slave），一個 Master 能夠將數據複製到多個 Slave，可是特別注意的是，複製是單向的，只能從 Master 到 Slave。一個 Master 能夠有多個 Slave，一個 Slave 也能夠有多個 Slave，可是一個 Slave 只能從屬一個 Master。以下圖這樣就是錯誤的。

主從複製的做用及場景

• 數據冗餘：主從複製實現了數據的熱備份，至關於一份數據在多個服務器上存儲了，是持久化以外的一種數據冗餘方式，這樣作的目的是以空間換取安全性。若是主服務器掛掉了，能夠經過從服務將數據恢復。
• 故障快速修復：當 Master 出現問題的時候，能夠快速地將一個 Slave 切換成 Master 繼續提供服務，保證項目穩定性。
• 讀寫分離：主從複製實現讀寫分離很是簡單，寫入的時候只操做 Master，讀取的時候只操做 Slave，這樣讀的話能夠多個 Slave 知足項目高併發的操做。
• 負載均衡：既然實現了讀寫分離，固然就能實現負載均衡，多個 Slave 承擔數據讀取操做，從而分擔 Master 服務器的壓力。
• 高可用的基石：主從複製仍是哨兵模式和集羣模式可以實施的基礎。

既然主從複製有這些做用，那在實際應用中會用在哪些場景呢？

• 若是項目對數據安全性穩定性要求較高，就會使用主從複製搭建哨兵模式或者搭建集羣。
• 海量數據讀寫，須要作讀寫分離提升防蚊效率，就會用到主從複製。
• 容災恢復，若是對數據依賴度很高，懼怕數據在服務器掛掉後丟失，就能夠經過主從複製防止數據丟失。

主從複製的模式

一主一從

這種模式在實際應用中仍是比較少見的其實，一主一從主要是實現讀寫分離和容災恢復。考慮到成本的問題，因此採用兩臺服務器，一個 Redis 服務器 Master 負責讀操做，並按期的複製到另個一服務器 Slave。Slave 服務器負責讀寫操做。在項目中配置的時候配置兩個 Redis 鏈接。

一主多從

一主多從有能夠分爲幾種，以下圖：

這種就是全部的 Slave 都從 Master 中進行復制，這樣的好處是 配置簡單，全部的 Slave 都只用關係 Master 就行了，可是要考慮到其實複製也是會侵佔 CPU 內存的，全部的 Slave 都從 Master 複製，可能增大 Master 的負荷。

再來看看下圖：

這種模式也是一主多從，可是和上面的全部的 Slave 都從 Master 複製不同。它是使一個到兩個 Slave 從 Master 直接複製，其餘的 Slave 從這兩個 Slave 中複製。存在層級關係。這樣的好處的下降的 Master 服務器的負荷，可是這樣會致使若是中間某個 Slave 掛掉了，那依附於它的全部 Slave 都不能用了。

主從複製的原理

上面以及搭建了一個主從複製的樣例，是一主兩從的，那是怎麼 Redis 是怎麼具體實現的呢？

在將原理以前，先來看看主從複製的幾個概念。啓動 Master 後：

127.0.0.1:6379> info server
# Server
redis_version:4.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:514e9a11b2a67dfc
redis_mode:standalone
os:Linux 5.0.0-23-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:7.4.0
process_id:19688
run_id:136de716105e54294144003a881ba29cdfbccfb2
tcp_port:6379
uptime_in_seconds:4515
uptime_in_days:0
hz:10
lru_clock:5556386
executable:/usr/local/redis/etc/redis-server
config_file:/usr/local/redis/etc/redis.conf複製代碼

這個 run_id 就是 Redis 服務的惟一標識，重啓 Redis 服務號，這個 run_id 會改變，多個 Redis 客戶端鏈接到同一個服務端，其 run_id 是同樣的，也就是說 run_id 指的是服務端的 id：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.252.53,port=6389,state=online,offset=5541,lag=1
slave1:ip=192.168.252.53,port=6399,state=online,offset=5541,lag=0
master_replid:f0c89aa8040dfe869de82ee623a1212240456d76
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5541
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5541複製代碼

其中 repl_backlog_size 複製緩存區大小，默認大小爲 1M，若是 mater_repl_offset 在這個範圍內，就看是部分複製，不然就開始全量複製。

全量複製

先看下圖，圖畫的不是很好見諒。

1. 首先 Slave 會向 Master 發送一個 psync 命令，由於是第一次，因此不知道 run_id 和 offset，因此傳過來 -1 表示全量複製。
2. Master 在接收到 psync 後，將 run_id 和 offset 發送給 Slave，Slave 存儲起來。
3. Master 進行 bgsave 生成 RDB，並將 RDB 文件發送給 Slave。
4. 在 bgsave 和 send RDB 的過程當中可能會產生 write 的數據，那麼就會把數據存到 repl_back_buffer 中 並將 buffer 發送給 Slave。
5. Slave 會清空就數據，而後加載 RDB 和 buffer 將數據存儲起來。

部分複製

既然是部分複製，那就是 Slave 已經知道了 Master 的 run_id 和 offset，因此發送 psync 命令帶上這兩個參數，Master 就知道這是部分複製，而後經過偏移量將須要複製的數據發送給 Slave。

總結

主從複製的過程當中既用到了全量複製也用到了部分複製，兩者是相互配合使用的。看下面的流程圖：

還有一點須要注意的是，若是 Master 重啓了，那麼它的 run_id 發生了改變，那麼依賴它的 Slave 都會進行一次全量複製後在進行部分複製。

最後

以爲不錯能夠點個贊支持一下！

更多技術文章請關注微信公衆號：以Java架構贏天下