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/)