簡介：Redis主從復制與優化

Redis主從復制與優化

主從復制

我們關注主從復制之前，首先要考慮單機有什么問題？

• 機器故障
• 容量瓶頸
• QPS瓶頸

這些都是單節點所遇到的問題，所以這個時候出現了主從復制（一主一從，一主多從）

使用主從復制可以：

• 數據副本
• 擴展讀性能

注意：

• 一個master可以有多個slave
• 一個slave只有一個master
• 數據流向是單向的，master到slave

---

主從復制的配置

兩種實現方式

• slaveof命令

兩臺機器：主節點：47.11.11.11 從節點 47.22.22.22

在從節點執行 slaveof 命令

47.22.22.22-6379 > slacefof 47.11.11.11 6379 OK

取消復制：

47.22.22.22-6379 > slacefof no one OK

• 修改配置

slaveof ip port //從節點ip + 端口 slave-read-only yes //開啟只做讀的操作

• 兩種方式比較

• 查看主從

127.0.0.1:6379> info replication # Replication role:master //主節點 connected_slaves:0 master_replid:1d43401335a5343b27b1638fc9843e3a593fc1a7 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0

---

知識點 ：

• 主節點 runID：

每個redis節點啟動后都會動態分配一個40位的十六進制字符串為運行ID。運行ID的主要作用是來唯一識別redis節點，比如從節點保存主節點的運行ID識別自已正在復制是哪個主節點。如果只使用ip+port的方式識別主節點，那么主節點重啟變更了整體數據集（如替換RDB/AOF文件），從節點再基于偏移量復制數據將是不安全的，因此當運行ID變化后從節點將做全量復制。可以在info server命令查看當前節點的運行ID。

需要注意的是redis關閉再啟動，運行的id會隨之變化。

---

全量復制和部分復制等

全量復制

用于初次復制或其它無法進行部分復制的情況，將主節點中的所有數據都發送給從節點。當數據量過大的時候，會造成很大的網絡開銷。

redis2.8+ 全量復制流程

開銷：

bgsave時間

RDB文件網絡傳輸

從節點清空數據時間

從節點加載RDB時間

可能的AOF重寫時間

部分復制

用于處理在主從復制中因網絡閃退等原因造成數據丟失場景，當從節點再次連上主節點，如果條件允許，主節點會補發丟失數據給從節點，因為補發的數據遠遠小于全量數據，可以有效避免全量復制的過高開銷。但需要注意，如果網絡中斷時間過長，造成主節點沒有能夠完整地保存中斷期間執行的寫命令，則無法進行部分復制，仍使用全量復制 。

流程：

復制偏移量：

• 參與復制的主從節點都會維護自身復制偏移量，主節點在處理完寫入命令操作后，會把命令的字節長度做累加記錄，統計信息在info replication中的master_repl_offset指標中。
• 從節點每秒鐘上報自身的復制偏移量給主節點，因此主節點也會保存從節點的復制偏移量slave0:ip=192.168.1.3,port=6379,state=online,offset=116424,lag=0
• 從節點在接收到主節點發送的命令后，也會累加記錄自身的偏移量。統計信息在info replication中的slave_repl_offset中。

復制積壓緩沖區：

• 復制積壓緩沖區是保存在主節點上的一個固定長度的隊列，默認大小為1MB，當主節點有連接的從節點時被創建，這時主節點響應寫命令時，不但會把命令發給從節點，還會寫入復制積壓緩沖區。
  在命令傳播階段，主節點除了將寫命令發送給從節點，還會發送一份給復制積壓緩沖區，作為寫命令的備份；除了存儲寫命令，復制積壓緩沖區中還存儲了其中 的每個字節對應的復制偏移量(offset) 。由于復制積壓緩沖區定長且先進先出，所以它保存的是主節點最近執行的寫命令；時間較早的寫命令會被擠出緩沖區。

---

生產中常見問題

讀寫分離

分流到從節點。主節點寫數據，從節點讀數據，可能遇到讀問題

復制數據延遲

讀到過期數據

從節點故障

主從配置不一致

例如maxmemory 不一致 會導致 丟失數據

例如數據結構優化參數（例如hash-max-ziplist-entries）:內存不一致

規避全量復制

第一次全量復制的時候
? - 第一次不可避免，盡量小節點 ，低峰處理

節點 運行ID不匹配
? - 故障轉移，例如哨兵或者集群

復制積壓緩存區不足
? - 增大復制緩存區配置rel_backlog_size ,網絡增強

規避復制風暴

單機器復制風暴（redis<4.0當master宕機重啟，會導致該機器下所有slave同時產生復制。避免單機部署一套redis主從）====》主節點分散多臺機

---

最后的注意事項：

• 在上述的過程的實現是從庫不開啟AOF持久化情況下,如果從庫開啟的AOF持久化，重啟時候依然使用全量復制。
• 之前從master復制過來的數據并不會丟失，只是不再同步之前master（如上圖的6379節點）后續寫入的數據
• slaveof 可以用來改變其所屬的master節點，即重新成為另一臺master的slave，但是新的master首先就會把從節點的數據全部清除掉
• 關于讀寫分離延時: 讀寫分離 ，master會一步將數據復制到slave，如果slave發生阻塞，則會延遲master數據的寫命令，造成數據不一致的問題。-------一般不考慮這個問題
• 讀到過期數據：redis在刪除key時有兩種策略，一種是懶惰型策略，即只有當redis操作這個key時才會將key刪除，第二種是定期采樣key刪除--------當key數據非常多時，采樣速度比不上key生成速度會造成很多過期數據沒有刪除，因為redis一般都是在master節點（增加刪除數據），slave查詢到過期數據也不能刪除。會導致slave讀到過期數據（在redis3.2中已經解決）
• 推薦 redis 主從文章https://www.cnblogs.com/wdliu/p/9407179.html
• 推薦 redis 全量復制與部分復制文章https://blog.csdn.net/gaobinzhan/article/details/106536326

個人博客：[http://blog.yanxiaolong.cn/](個人博客：http://blog.yanxiaolong.cn/
)

原文鏈接：https://developer.aliyun.com/article/775627?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的Redis主从复制与优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。