412 lines
13 KiB
Markdown
412 lines
13 KiB
Markdown
---
|
||
tags: [Redis, 缓存, 高可用, 主从, Sentinel]
|
||
create time: 2026-05-15 18:13
|
||
---
|
||
|
||
# Redis 主从复制与 Sentinel
|
||
|
||
## 概述
|
||
|
||
在生产环境中，单节点 Redis 存在两大问题：**写入能力有上限**、**宕机即停服**。本节介绍两个构建基础高可用的核心机制——
|
||
|
||
| 机制 | 解决什么问题 | 一句话说明 |
|
||
|------|------------|----------|
|
||
| **主从复制（Replication）** | 数据冗余 + 读扩展 | Master 处理写操作，Replica 自动同步数据并承担读请求 |
|
||
| **Sentinel（哨兵）** | 人工恢复慢 | 自动检测 Master 故障，提升最佳 Replica 为新 Master |
|
||
|
||
> [!SUMMARY] 知识定位
|
||
> - ✅ 本方案适合 **读多写少** 的场景（8:2 ~ 9:1）
|
||
> - ⚠️ 写入仍然集中在单点，若需水平写入 → [[hhs/Redis/07-集群方案]]
|
||
> - 🔧 这是学习 Redis Cluster 的前置知识
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Master["Master<br/>写操作入口"]
|
||
R1["Replica-1"]
|
||
R2["Replica-2"]
|
||
R3["Replica-3"]
|
||
|
||
Master -->|"全量/增量同步"| R1
|
||
Master -->|"全量/增量同步"| R2
|
||
Master -->|"全量/增量同步"| R3
|
||
|
||
ClientRW["写请求"] --> Master
|
||
ClientR["读请求"] --> R1
|
||
ClientR --> R2
|
||
ClientR --> R3
|
||
```
|
||
|
||
## 一、主从复制原理
|
||
|
||
### 异步 vs 半同步
|
||
|
||
> [!QUESTION] 为什么 Redis 选择异步复制？
|
||
> 如果等 Replica 确认后 Master 才返回客户端，那网络延迟 = 写入延迟。对于追求低延迟的场景（微秒级），这是不可接受的。
|
||
|
||
Redis 默认**异步复制**——Master 写完即返回客户端，不等待 Replica 确认。这保证了极致低延迟，代价是极端情况下可能丢失数据：
|
||
|
||
```text
|
||
场景: 写 A=1 → Master 返回 OK → Master 宕机（还没传到 Replica）→ 重启后 A 不存在
|
||
```
|
||
|
||
若业务需要 **至少一份副本落盘** 的强一致性保证，可配合 Lua + `wait` 命令实现弱半同步：
|
||
|
||
```go
|
||
// Go: 确保至少 N 个副本成功写入
|
||
numReplicas := 1 // 至少 1 个 replica 收到
|
||
timeout := 100 // 超时 100ms
|
||
result := client.Do(ctx, "WAIT", numReplicas, timeout).Int()
|
||
// result == 1 → 至少有 1 个副本已同步
|
||
```
|
||
|
||
> [!TIP] WAIT 的代价
|
||
> 阻塞当前线程直到满足条件或超时。高频写场景慎用，建议仅在关键事务中使用。
|
||
|
||
### 全量同步 vs 增量同步
|
||
|
||
> [!NOTE] PSync：一次连接，多次复用
|
||
> Redis 2.8+ 引入 PSYNC 协议替代旧版 SYNC，核心优势：**断线重连后可增量同步**。
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant R as Replica
|
||
participant M as Master
|
||
|
||
Note over R,M: ── 阶段 1: 全量同步（首次或断线过长）──
|
||
R->>M: PSYNC ? -1 (首次连接)
|
||
M->>M: BGSAVE → dump.rdb.tmp
|
||
M-->>R: +CONTENTS dump.rdb
|
||
R->>R: 重写本地数据集
|
||
|
||
loop 同步期间的新命令
|
||
M->>M: 追加到 repl-backlog-buffer
|
||
end
|
||
|
||
M-->>R: +CONTENTS buf (缓冲命令流)
|
||
R->>R: 重放缓冲命令
|
||
|
||
Note over R,M: ── 阶段 2: 增量同步（后续心跳）──
|
||
loop 通常 1 秒一次
|
||
R->>M: PSync <masterRunId> <offset>
|
||
M->>R: 发送 offset 之后的命令
|
||
end
|
||
```
|
||
|
||
#### 什么情况下触发全量同步？
|
||
|
||
| 触发条件 | 说明 |
|
||
|---------|------|
|
||
| 首次连接 | Replica 为空，必须下载完整 RDB |
|
||
| Master 重启 | Run ID 改变，无法增量恢复 |
|
||
| Replica 手动 SLAVEOF | 主动请求全量同步 |
|
||
| Backlog 过小 | 断线时间超出 repl-backlog-size 缓存容量 |
|
||
| config-resetstat 执行 | 元数据重置导致无法增量 |
|
||
|
||
### 复制背调（Replication Backlog）
|
||
|
||
每个 Master 内部维护一个固定大小的环形缓冲区（默认 1MB）：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
WriteHead["写入指针"] -->|"新命令流入"| Buffer["repl-backlog-buffer<br/>环形缓冲区(默认1MB)"]
|
||
ReadHead["读取指针"] -->|"命令回放给 Replica"--> Buffer
|
||
Buffer -->|"溢出"`覆盖最旧数据`"
|
||
```
|
||
|
||
```conf
|
||
# 相关配置
|
||
repl-backlog-size 256mb # 缓冲区大小，增大允许更长断线恢复
|
||
repl-backlog-ttl 3600 # 无人订阅时多久自动释放（秒）
|
||
```
|
||
|
||
**经验估算公式**：假设业务 QPS = 10,000，每条命令平均 50 字节，则每秒消耗 ~500KB 缓冲区。
|
||
- backlog = 1MB → 约支持 **2 秒** 断线恢复
|
||
- backlog = 256MB → 约支持 **8 分钟** 断线恢复
|
||
|
||
### 大键分裂问题（Big Key Split）
|
||
|
||
当某个 key 体积很大时（如几 MB 的 Hash/Set），一次 `SET` 会阻塞整个 Redis 进程数毫秒甚至更久。对 Replica 来说，这个命令在网络上传输也会成为瓶颈。
|
||
|
||
> [!SUMMARY] 如何发现大 Key？
|
||
> ```bash
|
||
> redis-cli --bigkeys # 在线扫描（谨慎！高 QPS 环境有性能影响）
|
||
> scan 0 MATCH * COUNT 100000 # 逐页扫描，用 type/hashlist/set 分别评估
|
||
> ```
|
||
|
||
解决方案：
|
||
- 写入侧：**分拆大 key** 为多个小 key（如按用户 ID 哈希分散）
|
||
- 同步侧：增大 `repl-diskless-sync-delay` 让多个 Replica 同时接收，避免重复传输
|
||
|
||
## 二、级联复制（拓扑优化）
|
||
|
||
当 Replica 数量增多时，每个都连 Master 会造成带宽压力：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Master["Master"]
|
||
R1["Replica-1<br/>(也接受从连接)"]
|
||
R2["Replica-2"]
|
||
R3["Replica-3"]
|
||
R4["Replica-4"]
|
||
|
||
Master --> R1
|
||
Master --> R2
|
||
R1 --> R3
|
||
R1 --> R4
|
||
```
|
||
|
||
> [!TIP] 最佳实践
|
||
> 只有 1~2 个 Replica 直接连 Master，其余通过级联获取数据。降低 Master 的网络和 CPU 负担。
|
||
|
||
## 三、只读副本注意事项
|
||
|
||
```conf
|
||
replica-read-only yes # 默认值
|
||
```
|
||
|
||
> [!WARNING] 禁止在 Replica 上写操作
|
||
> 即使关闭 `read-only`，Replica 上的写入在主从重新同步时会被清掉。而且 `DEL` 一个不存在的 key 也会触发额外命令发送给 Master。
|
||
|
||
### Replica 的其他关键配置
|
||
|
||
```conf
|
||
# --- 副本如何发现 Master ---
|
||
replica-announce-ip 192.168.1.20 # 对外宣告的 IP（Docker/NAT 环境下必设）
|
||
replica-announce-port 6379 # 对外宣告的端口
|
||
|
||
# --- Replica 是否可被查询 ---
|
||
replica-lazy-flush no # FULLRESYNC 后清空旧数据策略：no=立即 flush
|
||
replica-serve-stale-data yes # Master 不可达时是否继续服务请求（默认是）
|
||
replica-read-only yes # 只读保护
|
||
|
||
# --- 副本同步相关 ---
|
||
repl-diskless-sync no # 无盘复制开关
|
||
repl-diskless-sync-delay 5 # 等待其他副本同时连接的延迟（秒）
|
||
repl-timeout 60 # 同步超时阈值
|
||
```
|
||
|
||
## 四、核心参数调优参考
|
||
|
||
> [!NOTE] 根据业务特点选择合适的参数组合
|
||
|
||
### 方案 A：极致性能优先
|
||
|
||
```conf
|
||
# 适用于读 QPS > 50k，对一致性要求不高
|
||
repl-backlog-size 256mb # 大容量 backlog 减少全量同步
|
||
repl-diskless-sync yes # 无盘复制加速 RDB 传输
|
||
replica-lazy-flush no # 确保同步前快速清理旧数据
|
||
```
|
||
|
||
### 方案 B：一致性优先
|
||
|
||
```conf
|
||
# 适用于金融、账务等场景
|
||
WAIT 1 100 # 写入时确认至少 1 个副本成功
|
||
repl-backlog-size 512mb # 更大缓冲区容纳更多增量命令
|
||
```
|
||
|
||
### 常用调试命令
|
||
|
||
```bash
|
||
# 查看当前复制状态
|
||
redis-cli INFO replication
|
||
|
||
# 输出示例：
|
||
# role:master ← 或 replica
|
||
# connected_slaves:3
|
||
# master_repl_offset:12345678
|
||
# repl_backlog_active:1
|
||
# repl_backlog_size:268435456
|
||
```
|
||
|
||
## 五、Sentinel 哨兵机制
|
||
|
||
### 架构组成
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
S1["Sentinel-1"]
|
||
S2["Sentinel-2"]
|
||
S3["Sentinel-3"]
|
||
|
||
MasterNode["Master"]
|
||
RepNode["Replica"]
|
||
|
||
S1 <-->|心跳 PING/PONG| S2
|
||
S1 <-->|心跳 PING/PONG| S3
|
||
S2 <-->|心跳 PING/PONG| S3
|
||
|
||
S1 <--> MasterNode
|
||
S2 <--> MasterNode
|
||
S3 <--> MasterNode
|
||
|
||
MasterNode <--> RepNode
|
||
```
|
||
|
||
> [!QUESTION] 为什么需要奇数个 Sentinel？
|
||
> Sentinel 选举采用多数派原则（Quorum）。3 个节点中 2 个达成共识即可；5 个中需要 3 个。偶数增加 1 个 Sentinel 不会带来额外投票优势，反而浪费资源。
|
||
|
||
### 核心功能
|
||
|
||
#### 1. 监控（Monitoring）
|
||
|
||
```bash
|
||
# Sentinel 定期向 Master/Replica 发 PING
|
||
# Master 必须响应：PING → PONG 或 INFO
|
||
# Replica 同理
|
||
|
||
# 三种下线判断
|
||
1. SDOWN (Subjectively Down) — 某个 Sentinel 认为不可达
|
||
2. ODOWN (Objectively Down) — Quorum 数量的 Sentinel 都认为不可达
|
||
3. Failover in progress — 进入故障转移流程
|
||
```
|
||
|
||
#### 2. 选主（Leader Election）
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant S1 as Sentinel-1
|
||
participant S2 as Sentinel-2
|
||
participant S3 as Sentinel-3
|
||
|
||
S1->>S2: 提议自己为 leader (SEND ME YOUR VOTE)
|
||
S2->>S1: OK (投票给 S1)
|
||
S3->>S1: OK (投票给 S1)
|
||
S1->>S2: 我当选 leader
|
||
Note over S1,S3: ⚡ 任意 Sentinel 都可以主动发起选举
|
||
```
|
||
|
||
### 故障转移步骤
|
||
|
||
当 Master 被判定 ODOWN 后，Sentinel Leader 执行以下流程：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["1. 选出最佳 Replica"] --> B["评估标准:<br/>复制偏移量 > 优先级 > RunID"]
|
||
B --> C["SLAVEOF NO ONE<br/>提升为新 Master"]
|
||
C --> D["其他 Replica → SLAVEOF new-master"]
|
||
D --> E["更新集群元数据"]
|
||
E --> F["通知客户端新地址"]
|
||
```
|
||
|
||
**最佳 Replica 选择标准**（按优先级排序）：
|
||
1. **复制偏移量最大** — 离最新数据的 Replica 优先
|
||
2. **`replica-priority` 最小** — 值越小越优先当选（0 = 不可当选）
|
||
3. **Run ID 字典序最小** — 作为最终 tie-breaker
|
||
|
||
### Sentinel 配置文件
|
||
|
||
```conf
|
||
sentinel monitor mymaster 192.168.1.10 6379 2
|
||
# ↑ name ↑ host port quorum(达成SDOWN共识的个数)
|
||
|
||
sentinel auth-pass mymaster your-password
|
||
|
||
# 多久无响应即标记 SDOWN（毫秒）
|
||
sentinel down-after-milliseconds mymaster 30000
|
||
|
||
# 故障转移超时（毫秒），超过则失败重试
|
||
sentinel failover-timeout mymaster 180000
|
||
|
||
# 最多多少 Replica 同时与新 Master 同步
|
||
sentinel parallel-syncs mymaster 1
|
||
```
|
||
|
||
> [!WARNING] Sentinel 配置陷阱
|
||
> - `down-after-milliseconds` 不要设太低（如 1s），网络抖动会导致误判；建议 **15~30 秒**
|
||
> - `failover-timeout` 不宜太短，防止频繁重试加重系统负载
|
||
> - `parallel-syncs` 设为 1 可避免转移期间所有 Replica 同时不可用
|
||
> - **生产环境建议手动维护 Sentinel 配置**，避免自动感知的不确定性
|
||
> - Redis 6+ 启用 ACL 后，需配置 `sentinel user/myuser password/mypass` 而非 `auth-pass`
|
||
|
||
### Sentinel 下的客户端连接
|
||
|
||
Go 和 Python 生态都提供了原生支持——客户端内部自动发现 Master/Replica，故障时重新连接。
|
||
|
||
```go
|
||
// go-redis: 原生 Sentinel 模式
|
||
rdb, err := redis.NewFailoverClient(&redis.FailoverOptions{
|
||
MasterName: "mymaster",
|
||
SentinelAddrs: []string{"sento1:26379", "sento2:26379", "sento3:26379"},
|
||
Password: "your-password",
|
||
MaxRetries: 3,
|
||
RetryDelay: 500 * time.Millisecond,
|
||
})
|
||
// 读请求走 Replica，写请求走 Master
|
||
_ = rdb.Get(ctx, "key")
|
||
```
|
||
|
||
```python
|
||
# redis-py Sentinel
|
||
from redis.sentinel import Sentinel
|
||
|
||
sentinel = Sentinel([('sento1', 26379), ('sento2', 26379), ('sento3', 26379)])
|
||
master = sentinel.master_for('mymaster', password='your-password') # 写
|
||
slave = sentinel.slave_for('mymaster', password='your-password') # 读
|
||
```
|
||
|
||
## 五、生产实践 checklist
|
||
|
||
### 部署前
|
||
|
||
- [ ] **Sentinel 节点数 ≥ 3**，奇数个，部署在不同可用区或机器上
|
||
- [ ] **Master + Replica 数量建议 1:2 ~ 1:3**，过多会影响同步延迟
|
||
- [ ] **`replica-priority` 设值**：不可作为 Master 的设为 `0`
|
||
- [ ] **持久化策略一致**：Master 和 Replica 的 RDB/AOF 策略应相同
|
||
|
||
### 监控项
|
||
|
||
```bash
|
||
# 关键指标（每秒采样）
|
||
INFO replication # connected_slaves, master_repl_offset
|
||
INFO memory # used_memory_human (同步期间会突增)
|
||
INFO stats # instantaneous_ops_per_sec
|
||
```
|
||
|
||
### 故障排查流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["发现 Master 异常"] --> B{"Sentinel 是否已 ODOWN?"}
|
||
B -->|"是"| C["自动 Failover 中..."]
|
||
B -->|"否"| D["检查网络 / CPU / 大 Key 阻塞"]
|
||
C --> E["Failover 成功?"]
|
||
E -->|"是"| F["客户端已自动切换 ✓"]
|
||
E -->|"否"| G["手动干预:<br/>SENTINEL FAILOVER mymaster"]
|
||
D --> H["问题解决后<br/>重新加入复制拓扑"]
|
||
```
|
||
|
||
### 常见坑点汇总
|
||
|
||
| 坑 | 现象 | 解决 |
|
||
|---|------|------|
|
||
| Docker 环境下 IP 错乱 | Sentinel 记录了容器的内部 IP | 设置 `replica-announce-ip` |
|
||
| 脑裂（Split Brain） | 网络分区后 Master 仍处理写请求 | 用 `min-replicas-to-write 1` 保护 |
|
||
| OOM during BGSAVE | fork 子进程导致内存翻倍 | 关闭 THP，增大 swap，限制 maxmemory |
|
||
|
||
> [!NOTE] 防脑裂配置
|
||
> ```conf
|
||
> # Master 端配置：至少 N 个 Replica 在线才接受写入
|
||
> min-replicas-to-write 1
|
||
> # 对应的最大允许延迟（秒），超时视为掉线
|
||
> min-replicas-max-lag 10
|
||
> ```
|
||
|
||
## 六、局限性与替代方案
|
||
|
||
| 问题 | Sentinel 无法解决 |
|
||
|------|----------------|
|
||
| 单 Master 写入瓶颈 | ❌ 只有一个 Master |
|
||
| 数据量超限单机容量 | ❌ |
|
||
| 跨机房容灾 | ❌（Sentinel 跨网段延迟太高） |
|
||
|
||
> [!TIP] 需要水平扩展？看 Cluster 方案 → [[hhs/Redis/07-集群方案]]
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/Redis/07-集群方案]] — Cluster 架构（水平扩展）
|
||
- [[hhs/Redis/09-运维调优]] — 监控与告警配置
|
||
- [[hhs/Redis/04-AOF持久化]] — AOF 与 RDB 结合的高可用策略
|
||
- [[hhs/EXAM/Week05]] — Docker Compose 中的部署示例
|