搞懂Redis復制原理
前言
與大多數db一樣，Redis也提供了復制機制，以滿足故障恢復和負載均衡等需求。復制也是Redis高可用的基礎，哨兵和集群都是建立在復制基礎上實現高可用的。復制不僅提高了整個系統的容錯能力，還可以水平擴展，實現在一個重讀取的應用中，通過增加多個Redis只讀從實例來減輕主實例的壓力。
本文主要介紹Redis復制機制
一.配置與實踐
配置
Redis實例分為主節點（master）和從節點（slave），默認情況下都是主節點。每一個從節點只能有一個主節點，但是每一個主節點可以有多個從節點（註意數量，多個從節點會導致主節點寫命令多次發送從而過度消耗網絡帶寬，可用樹狀結構降低主節點負載
- 在redis-slave.conf配置文件中加入slaveof {masterHost} {masterPort}
- 在redis-server啟動命令後加入 --slaveof {masterHost} {masterPort}
- 啟動後直接使用命令slaveof {masterHost} {masterPort}
綜上，Redis支持在啟動之前配置，也支持運行中動態配置。
實踐
我們用動態配置的方法來配置，先起一個端口為6379的Redis實例，作為主節點：
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis.conf
再起一個端口為6380的Redis實例，作為6379的從節點：
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis-slave.conf
用客戶端連到從節點，使用slaveof命令，slaveof配置都是在從節點發起的。
127.0.0.1:6380> slaveof 127.0.0.1 6379 OK
從節點日誌：
75585:S 06 May 16:27:50.389 * Connecting to MASTER 127.0.0.1:6379 75585:S 06May 16:27:50.389 * MASTER <-> SLAVE sync started 75585:S 06 May 16:27:50.390 * Non blocking connect for SYNC fired the event. 75585:S 06 May 16:27:50.390 * Master replied to PING, replication can continue... 75585:S 06 May 16:27:50.390 * Trying a partial resynchronization (request 47770067272eb8101489fe7c00c8e838125c3aa3:1). 75585:S 06 May 16:27:50.392 * Full resync from master: e91e683b1e13332f97ecb9fa90ecdace460ab4ca:0 75585:S 06 May 16:27:50.392 * Discarding previously cached master state. 75585:S 06 May 16:27:50.491 * MASTER <-> SLAVE sync: receiving 215 bytes from master 75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Flushing old data 75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Loading DB in memory 75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Finished with success
主節點日誌：
75553:M 06 May 16:27:50.391 * Slave 127.0.0.1:6380 asks for synchronization 75553:M 06 May 16:27:50.391 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for ‘47770067272eb8101489fe7c00c8e838125c3aa3‘, my replication IDs are ‘160af1c75f86edc50186e3e4a4dc6ecb5e3fa586‘ and ‘0000000000000000000000000000000000000000‘) 75553:M 06 May 16:27:50.391 * Starting BGSAVE for SYNC with target: disk 75553:M 06 May 16:27:50.391 * Background saving started by pid 75675 75675:C 06 May 16:27:50.395 * DB saved on disk 75553:M 06 May 16:27:50.490 * Background saving terminated with success 75553:M 06 May 16:27:50.491 * Synchronization with slave 127.0.0.1:6380 succeeded
可以看到，第一次建立復制關系的時候，主節點和從節點進行了一次全量復制，見圖：
當完成復制的建立之後，接下來主節點會持續的把寫命令發送給從節點，保證主從數據一致。
在主實例上添加新的key：
127.0.0.1:6379> set Lin 112131 OK
在從實例查看剛剛添加的key：
127.0.0.1:6380> get Lin "112131"
只讀
由於復制只能從主節點到從節點，對於從節點的數據修改主節點無法感知，為了避免主從實例之間的數據不一致。從節點默認配置為只讀模式：
slave-read-only yes
二.工作原理
我們先講3個比較關鍵的參數：master_replid、master_repl_offset和slave_repl_offset。我們分別在master6379和slave6380上執行info replication
127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=1093,lag=1 master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1093 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1093 127.0.0.1:6380> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:9 master_sync_in_progress:0 slave_repl_offset:1107 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1107 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1107
- master_replid是master啟動時生成的隨機字符串，用來標識主實例
- master_repl_offset是復制流中的一個偏移量，master處理完寫入命令後，會把命令的字節長度做累加記錄，統計在該字段。該字段也是實現部分復制的關鍵字段。
- slave_repl_offset同樣也是一個偏移量，從節點收到主節點發送的命令後，累加自身的偏移量，通過比較主從節點的復制偏移量可以判斷主從節點數據是否一致。
當從實例連接到主實例時，從實例會發送master_replid和master_repl_offset（標識與主實例同步的最後一個快照）請求部分復制。如果主實例接收部分復制的話則從最後一個偏移量開始增量進行部分復制，否則將進行全量復制。如圖：
三.數據同步
Redis在2.8之前使用sync命令完成主從數據同步，Redis在2.8及以上使用psync命令完成主從數據同步，同步過程分為：全量復制和部分復制
全量復制
全量復制是Redis最早支持的復制方式，也是主從第一次建立復制的時候必須經歷的。它會把主節點全部數據一次性發送給從節點，當數據量較大的時候，會對主從節點和網絡造成很大開銷。主節點執行bgsave保存RDB文件，然後將這個文件發送給從節點，從節點收到RDB文件後，會先將內存中的所有數據清除，然後再將RDB文件中的數據導入。
主實例在復制過程中是完全異步的，因此不會阻塞主節點的請求。在這一期間內主節點的所有寫入命令數據都保存在從客戶端緩沖區（slave client buffer）內，在從節點加載完RDB文件後，主節點會將這個緩沖區的內容發送給從節點。
從客戶端緩沖區默認大小限制為：
client-output-buffer-limit slave 256mb 64mb 60
意思是如果60秒內緩沖區消耗持續大於64MB或者直接超過256MB時，主節點將直接關閉復制客戶端連接，造成全量同步失敗。
部分復制
在高版本的Redis實現中，master_replid和offset存儲在RDB文件中。當從實例在復制過程中，因網絡閃斷等原因造成的數據丟失場景，Redis能夠從rdb文件中重新加載master_replid和offset，從而使部分重新同步成為可能。因為補發的數據遠小於全量數據，所以可以有效的避免全量復制帶來的負載和消耗。
之前說過，從節點連接主節點之後，會使用master_replid和master_repl_offset請求主節點，首先判斷master_replid是否和自己的master_replid一致，然後檢查請求中的master_repl_offset是否能從緩沖區（replication backlog）中獲取，如果偏移量在backlog範圍內，那麽可以進行部分復制。如果在斷開連接期間主節點收到的寫入命令的數量超過了backlog緩沖區的容量，那麽會進行全量復制。默認情況下backlog為1MB。
參考
基本和redis篇第一個帖子一樣：
https://www.cnblogs.com/GrimMjx/p/10662254.html
搞懂Redis復制原理