1. Redis主從複制原理
1.1 主從架構
redis主從架構 -> 讀寫分離架構 -> 可支援水準擴充的讀高并發架構
架構做成主從架構，一主多從，主負責寫，從負責讀。資料同步時，将master的資料同步複制到其他slave節點。
水準擴容，就是說，當QPS在增加，隻要增加redis slave節點即可
1.2 主從架構的核心原理
當啟動一個slave node的時候，它會發送一個PSYNC指令給master node
如果這是slave node重新連接配接master node，那麼master node僅僅會複制給slave部分缺少的資料; 否則如果是slave node第一次連接配接master node，那麼會觸發一次full resynchronization
開始full resynchronization的時候，master會啟動一個背景線程，開始生成一份RDB快照檔案，同時還會将從用戶端收到的所有寫指令緩存在記憶體中。RDB檔案生成完畢之後，master會将這個RDB發送給slave，slave會先寫入本地磁盤，然後再從本地磁盤加載到記憶體中。然後master會将記憶體中緩存的寫指令發送給slave，slave也會同步這些資料。
slave node如果跟master node有網絡故障，斷開了連接配接，會自動重連。master如果發現有多個slave node都來重新連接配接，僅僅會啟動一個rdb save操作，用一份資料服務所有slave node。
1.3 主從複制的3個feature
- 斷點續傳
從redis 2.8開始，就支援主從複制的斷點續傳，如果主從複制過程中，網絡連接配接斷掉了，那麼可以接着上次複制的地方，繼續複制下去，而不是從頭開始複制一份
master node會在記憶體中常見一個backlog，master和slave都會儲存一個replica offset還有一個master id，offset就是儲存在backlog中的。如果master和slave網絡連接配接斷掉了，slave會讓master從上次的replica offset開始繼續複制
但是如果沒有找到對應的offset，那麼就會執行一次resynchronization
- 無磁盤化複制
master在記憶體中直接建立rdb，然後發送給slave，不會在自己本地落地磁盤了
repl-diskless-sync
repl-diskless-sync-delay，等待一定時長再開始複制，因為要等更多slave重新連接配接過來
- 過期key處理
slave不會過期key，隻會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模拟一條del指令發送給slave。
2. redis replication的完整流運作程和原理
2.1 複制的完整流程
- slave node啟動，僅僅儲存master node的資訊，包括master node的host和ip，但是複制流程沒開始master host和ip是從哪兒來的，redis.conf裡面的slaveof配置的
- slave node内部有個定時任務，每秒檢查是否有新的master node要連接配接和複制，如果發現，就跟master node建立socket網絡連接配接
- slave node發送ping指令給master node
- 密碼認證，如果master設定了requirepass，那麼salve node必須發送masterauth的密碼過去進行認證
- master node第一次執行全量複制，将所有資料發給slave node
- master node後續持續将寫指令，異步複制給slave node
2.2 資料同步相關的核心機制
指的就是第一次slave連接配接master的時候，執行的全量複制，此過程裡的一些細節的機制
- master和slave都會維護一個offset
master會在自身不斷累加offset，slave也會在自身不斷累加offset
slave每秒都會上報自己的offset給master，同時master也會儲存每個slave的offset
這個倒不是說特定就用在全量複制的，主要是master和slave都要知道各自的資料的offset，才能知道互相之間的資料不一緻的情況
記錄offset可以知道slave從master複制到了那個地方
- backlog
master node有一個backlog，預設是1MB大小
master node給slave node複制資料時，也會将資料在backlog中同步寫一份
backlog主要是用來做全量複制中斷候的增量複制的
- master run id
info server，可以看到master run id
如果根據host+ip定位master node，是不靠譜的，如果master node重新開機或者資料出現了變化，那麼slave node應該根據不同的run id區分，run id不同就做全量複制
如果需要不更改run id重新開機redis，可以使用redis-cli debug reload指令
- psync
從節點使用psync從master node進行複制，psync runid offset
master node會根據自身的情況傳回響應資訊，可能是FULLRESYNC runid offset觸發全量複制，可能是CONTINUE觸發增量複制
2.3 全量複制
- master執行bgsave，在本地生成一份rdb快照檔案
- master node将rdb快照檔案發送給salve node，如果rdb複制時間超過60秒（repl-timeout），那麼slave node就會認為複制失敗，可以适當調節大這個參數
- 對于千兆網卡的機器(伺服器内網标配)，一般每秒傳輸100MB，6G檔案，很可能超過60s
- master node在生成rdb時，會将所有新的寫指令緩存在記憶體中，在salve node儲存了rdb之後，再将新的寫指令複制給salve node
- client-output-buffer-limit slave 256MB 64MB 60，如果在複制期間，記憶體緩沖區持續消耗超過64MB，或者一次性超過256MB，那麼停止複制，複制失敗
- slave node接收到rdb之後，清空自己的舊資料，然後重新加載rdb到自己的記憶體中，同時基于新的資料版本對外提供服務
- 如果slave node開啟了AOF，那麼會立即執行BGREWRITEAOF，重寫AOF
rdb生成、rdb通過網絡拷貝、slave舊資料的清理、slave aof rewrite，很耗費時間
如果複制的資料量在4G~6G之間，那麼很可能全量複制時間消耗到1分半到2分鐘
一般對單機而言 redis記憶體4-6g
2.4 增量複制
- 如果全量複制過程中，master-slave網絡連接配接斷掉，那麼salve重新連接配接master時，會觸發增量複制
- master直接從自己的backlog中擷取部分丢失的資料，發送給slave node，預設backlog就是1MB
- msater就是根據slave發送的psync中的offset來從backlog中擷取資料的
2.5 heartbeat
主從節點互相都會發送heartbeat資訊
master預設每隔10秒發送一次heartbeat，salve node每隔1秒發送一個heartbeat
2.6 異步複制
master每次接收到寫指令之後，現在内部寫入資料，然後異步發送給slave node
3. Redis replication以及master持久化對主從架構的安全意義
3.1 Redis replication的核心機制
- redis采用異步方式複制資料到slave節點，不過redis 2.8開始，slave node會周期性地确認自己每次複制的資料量
- 一個master node是可以配置多個slave node的
- slave node也可以連接配接其他的slave node
- slave node做複制的時候，是不會block master node的正常工作的
- slave node在做複制的時候，也不會block對自己的查詢操作，它會用舊的資料集來提供服務; 但是複制完成的時候，需要删除舊資料集，加載新資料集，這個時候就會暫停對外服務了
- slave node主要用來進行橫向擴容，做讀寫分離，擴容的slave node可以提高讀的吞吐量
slave，高可用性，有很大的關系
3.2 master持久化對于主從架構的安全保障的意義
- 如果采用了主從架構，那麼建議必須開啟master node的持久化！
不建議用slave node作為master node的資料熱備，因為那樣的話，如果你關掉master的持久化，可能在master當機重新開機的時候資料是空的，然後可能一經過複制，salve node資料也丢了
master -> RDB和AOF都關閉了 -> 全部在記憶體中
master當機，重新開機，是沒有本地資料可以恢複的，然後就會直接認為自己IDE資料是空的
master就會将空的資料集同步到slave上去，所有slave的資料全部清空,最後導緻100%的資料丢失
master節點，必須要使用持久化機制
- 第二，確定master的各種備份方案，萬一說本地的所有檔案丢失了; 從備份中挑選一份rdb去恢複master; 這樣才能確定master啟動的時候，是有資料的
即使采用了後續講解的高可用機制，slave node可以自動接管master node，但是也可能sentinal還沒有檢測到master failure，master node就自動重新開機了，還是可能導緻上面的所有slave node資料清空故障
關于持久化可以看看這篇文章
https://blog.csdn.net/illusory_germ/article/details/100926774