Redis中主從同步機制的示例分析

# Redis中主從同步機制的示例分析

## 一、Redis主從同步概述

### 1.1 主從架構的基本概念
Redis主從復制（Master-Slave Replication）是指將一臺Redis服務器的數據，復制到其他Redis服務器的過程。源服務器稱為主節點（Master），接收復制的服務器稱為從節點（Slave）。這種架構設計主要帶來以下優勢：

- **數據冗余**：實現數據的熱備份
- **故障恢復**：當主節點出現問題時，可以快速切換到從節點
- **負載均衡**：讀寫分離模式下，主節點負責寫，從節點承擔讀請求
- **高可用基石**：是Redis Sentinel和Cluster實現的基礎

### 1.2 同步機制發展歷程
Redis的主從同步機制經歷了多個版本的演進：

| 版本 | 主要改進 |
|------|----------|
| 2.8之前 | 僅支持全量同步 |
| 2.8-4.0 | 引入PSYNC部分重同步 |
| 4.0+ | 優化PSYNC2，支持故障轉移后的部分同步 |
| 6.0+ | 無盤復制改進，多線程復制支持 |

## 二、同步機制核心原理

### 2.1 全量同步（Full Resynchronization）

**觸發場景**：
- 從節點首次連接主節點
- 從節點保存的replid與主節點不一致
- 復制積壓緩沖區不足（offset不在緩沖范圍內）

**執行流程**：
```python
def full_sync():
    # 1. 從節點發送PSYNC命令
    slave.send("PSYNC ? -1") 
    
    # 2. 主節點響應FULLRESYNC
    master.reply("FULLRESYNC replid offset")
    
    # 3. 主節點執行BGSAVE生成RDB
    master.bgsave()
    
    # 4. 傳輸RDB文件
    master.send_rdb_to(slave)
    
    # 5. 傳輸緩沖期間的寫命令
    master.send_repl_buffer(slave)

關鍵參數： - repl-timeout：默認60秒，超時判定同步失敗 - client-output-buffer-limit：限制復制緩沖區大小

2.2 部分同步（Partial Resynchronization）

核心組件： 1. Replication ID：每個主節點唯一標識，重啟或提升從節點時會改變 2. Offset：復制偏移量，主從節點各自維護 3. Repl Backlog：環形緩沖區，默認大小1MB

工作流程示例：

sequenceDiagram
    participant S as Slave
    participant M as Master
    
    S->>M: PSYNC <replid> <offset>
    alt offset在backlog范圍內
        M->>S: CONTINUE
        M->>S: 發送缺失的命令
    else
        M->>S: FULLRESYNC
    end

2.3 無盤復制（Diskless Replication）

Redis 4.0引入的優化方案：

# 配置項
repl-diskless-sync yes
repl-diskless-sync-delay 5

工作特點： - 主節點直接通過socket發送RDB數據 - 適用于磁盤IO慢的云環境 - 多個從節點可以共享同一輪RDB傳輸

三、典型場景示例分析

3.1 新從節點加入集群

操作步驟： 1. 配置從節點：

   SLAVEOF 192.168.1.100 6379

1. 主節點日志示例：

   
   [1234] 01 Jan 12:00:00.123 * Slave 192.168.1.101:6379 asks for synchronization
   [1234] 01 Jan 12:00:00.124 * Full resync requested by slave 192.168.1.101:6379
   [1234] 01 Jan 12:00:00.125 * Starting BGSAVE for SYNC with target: disk
   

內存變化監控：

redis-cli info memory
# 觀察used_memory_peak變化

3.2 網絡閃斷后的恢復

異常場景模擬： 1. 主動斷開從節點網絡：

   iptables -A INPUT -p tcp --dport 6379 -j DROP

1. 30秒后恢復網絡

正?；謴腿罩?/strong>：

[1234] 01 Jan 12:05:00.456 * Slave 192.168.1.101:6379 is back online with 500 bytes of backlog
[1234] 01 Jan 12:05:00.457 * Partial resynchronization request accepted

  CONFIG SET repl-backlog-size 100mb

[2345] 01 Jan 12:10:00.789 * Trying a partial resynchronization (request 2b3...:1000).
[2345] 01 Jan 12:10:00.790 * Successful partial resynchronization with master.

redis-cli info replication

role:master
connected_slaves:2
slave0:ip=192.168.1.101,port=6379,state=online,offset=1000,lag=0
master_replid:2b3f5c19...
master_repl_offset:1000

- job_name: 'redis_replication'
  metrics_path: '/metrics'
  static_configs:
    - targets: ['redis-exporter:9121']

   iperf -c redis-master

redis-cli --eval check_sync.lua

local info = redis.call('info', 'replication')
local offset = tonumber(string.match(info, "master_repl_offset:(%d+)"))
local slave_offset = tonumber(string.match(info, "slave0:offset=(%d+)"))
return {offset, slave_offset, offset - slave_offset}