vault backup: 2026-05-27 00:12:00
This commit is contained in:
+195
-27
@@ -107,56 +107,156 @@ if replicaCount >= 1 {
|
||||
|
||||
### 全量同步 vs 增量同步
|
||||
|
||||
主从同步分为两种模式，理解它们的前提是知道一个关键概念：**Replication Offset（复制偏移量）**——你可以把它想象成一条数据"流水线"上的**刻度尺**。Master 每写入一条命令，刻度就往后移一点；Replica 同步到哪里了，也有自己的刻度。只要两个刻度对得上，就能"增量同步"。
|
||||
回到"抄作业"的类比：你缺了一整学期的笔记，那就得**全量抄一本**（全量同步）；你只是昨天请了一天假，那就**只抄昨天那几页**（增量同步）。Redis 的主从同步也一样，分这两种模式：
|
||||
|
||||
> [!NOTE] PSync：一次连接，多次复用
|
||||
> Redis 2.8+ 引入 PSYNC 协议替代旧版 SYNC，核心优势：**断线重连后可增量同步**。旧版 SYNC 每次断线都得全量传输（相当于每次请假都得抄一整本笔记），PSYNC 改为"只抄你缺的那几页"。
|
||||
- **全量同步（Full Resync）**：Master 把**整个数据集**打包成 RDB 文件发给 Replica。适用于首次连接、断线太久等场景。代价大，应尽量避免
|
||||
- **增量同步（Partial Resync）**：Master 只发送 **Replica 缺失的那部分命令**。适用于正常运行期间的短暂断线。代价小，是常态
|
||||
|
||||
> [!QUESTION] 那 Redis 怎么判断应该走"全量"还是"增量"呢？
|
||||
> 这就要说到两个关键的"身份标识"——Run ID 和 Replication Offset。
|
||||
|
||||
#### 前置概念：两个关键标识
|
||||
|
||||
要理解全量/增量的判断逻辑，需要先搞清楚两个东西：
|
||||
|
||||
**1. Run ID —— "你是哪个 Master？"**
|
||||
|
||||
每个 Redis 实例启动时会随机生成一个 40 字符的唯一标识符（如 `8b1f8a3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a`）。Replica 第一次连接 Master 时会记住它的 Run ID。之后每次重连，Replica 先报出"我记得的 Run ID"，Master 对比：
|
||||
|
||||
- **Run ID 匹配** → "你还认识我" → 有可能增量同步
|
||||
- **Run ID 不匹配** → "我不认识你"（Master 重启了 / 换了台机器）→ 只能全量同步
|
||||
|
||||
**2. Replication Offset —— "你同步到哪了？"**
|
||||
|
||||
你可以把它想象成一条**数据流水线上的刻度尺**。Master 和 Replica 各自维护一个 offset：
|
||||
|
||||
- Master 每写入一条命令，offset 就往后移（比如从 `1000` 到 `1050`）
|
||||
- Replica 每同步一条命令，自己的 offset 也往后移
|
||||
- 只要 Master 的 **backlog 缓冲区** 里还保留着 Replica 需要的那段数据（即 Replica 的 offset 在 backlog 覆盖范围内），就能增量同步
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Identity["两个身份标识"]
|
||||
RunID["Run ID<br/>回答: 你是哪个 Master?"]
|
||||
Offset["Replication Offset<br/>回答: 我同步到哪了?"]
|
||||
end
|
||||
|
||||
RunID -->|"匹配"| CheckOffset["检查 Offset"]
|
||||
RunID -->|"不匹配"| FullSync["只能全量同步"]
|
||||
CheckOffset -->|"Offset 在 backlog 范围内"| PartialSync["增量同步"]
|
||||
CheckOffset -->|"Offset 已被覆盖"| FullSync
|
||||
```
|
||||
|
||||
> [!NOTE] PSYNC 协议：让增量同步成为可能
|
||||
> Redis 2.8 之前用的是 `SYNC` 命令，**每次断线都全量传输**——相当于你每次请假都得抄一整本笔记，不管你只缺一天还是缺一个月。Redis 2.8+ 引入了 `PSYNC` 协议，Replica 重连时带上 Run ID 和自己的 Offset，Master 就能判断"你只缺了一点"还是"你缺太多了"，从而决定增量还是全量。
|
||||
|
||||
#### 全量同步：逐步拆解
|
||||
|
||||
全量同步发生在 **首次连接** 或 **断线太久导致增量同步不可能** 的场景。整个过程分为三个阶段：
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant R as Replica
|
||||
participant M as Master
|
||||
|
||||
Note over R,M: "阶段 1: 全量同步（首次连接或断线过久）"
|
||||
R->>M: PSYNC ? -1 (首次连接, 没有 offset 记录)
|
||||
M->>M: 触发 BGSAVE, 生成 RDB 快照文件
|
||||
M-->>R: +FULLRESYNC <runId> <offset>, 然后发送 RDB 文件
|
||||
Note over R,M: "阶段 1: 握手与身份确认"
|
||||
R->>M: PSYNC ? -1
|
||||
Note right of R: "? = 我不知道你的 Run ID<br/>-1 = 我没有 offset 记录"
|
||||
M->>M: 执行 BGSAVE 生成 RDB 快照
|
||||
M-->>R: "+FULLRESYNC <runId> <offset>"
|
||||
Note left of M: "意思是: 好, 全量同步,<br/>我的 Run ID 是 xxx,<br/>当前 offset 是 yyy"
|
||||
M-->>R: 发送 RDB 文件
|
||||
R->>R: 清空旧数据, 用 RDB 全量覆盖
|
||||
|
||||
Note over M: "RDB 生成期间, 新的写入命令不能丢"
|
||||
Note over R,M: "阶段 2: RDB 传输期间的新写入不能丢"
|
||||
Note over M: "BGSAVE 期间, 客户端仍在写入"
|
||||
loop "RDB 传输期间的新写入"
|
||||
M->>M: 追加到 repl-backlog-buffer
|
||||
M->>M: 新命令追加到 repl-backlog-buffer
|
||||
end
|
||||
|
||||
M-->>R: 发送 backlog 中缓存的命令流
|
||||
R->>R: 重放缓冲命令, 追上 Master 的进度
|
||||
Note over R,M: "阶段 3: 发送缓冲命令, 追赶进度"
|
||||
M-->>R: 发送 backlog 中缓存的增量命令
|
||||
R->>R: 逐条重放, 追上 Master 最新进度
|
||||
```
|
||||
|
||||
Note over R,M: "阶段 2: 增量同步（后续心跳, 每秒一次）"
|
||||
loop "正常运行期间"
|
||||
R->>M: PSYNC <masterRunId> <myOffset>
|
||||
M->>R: 只发送 offset 之后的增量命令
|
||||
> [!NOTE] 阶段 2 为什么不会丢数据？
|
||||
> 你可能会担心：BGSAVE 是某一时刻的快照，那快照之后到 RDB 传输完成这段时间的写入怎么办？答案是 **backlog 缓冲区**。Master 在生成 RDB 的同时，会把所有新写入的命令追加到 backlog 里，等 RDB 传完后再把这些缓冲命令发给 Replica。所以 Replica 先拿到"截止到某个时间点的完整快照"，再拿到"快照之后的增量命令"，两者拼起来就是完整的最新数据。
|
||||
|
||||
#### 增量同步：逐步拆解
|
||||
|
||||
增量同步是 **正常运行时的常态**。Replica 短暂断线后重连，只需要补齐断线期间缺失的命令：
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant R as Replica
|
||||
participant M as Master
|
||||
|
||||
Note over R,M: "Replica 短暂断线后重连"
|
||||
R->>M: PSYNC <runId> <myOffset>
|
||||
Note right of R: "我认识你, Run ID 是 xxx,<br/>我的 offset 是 10000"
|
||||
M->>M: 检查 runId 匹配<br/>检查 offset 10000 是否在 backlog 范围内
|
||||
|
||||
alt "offset 在 backlog 范围内 → 增量同步"
|
||||
M-->>R: "+CONTINUE"
|
||||
M-->>R: 发送 offset 10000 之后的增量命令
|
||||
Note left of M: "只发你缺的 10001 ~ 10500,<br/>不用重传整个数据集"
|
||||
R->>R: 重放增量命令, offset 追到 10500
|
||||
else "offset 已被覆盖 → 退化为全量同步"
|
||||
M-->>R: "+FULLRESYNC"
|
||||
Note left of M: "你缺的太多了, 增量同步<br/>不可能了, 转为全量重传"
|
||||
end
|
||||
```
|
||||
|
||||
> [!QUESTION] 全量同步的代价是什么？
|
||||
> 全量同步需要 Master 执行 `BGSAVE`（fork 子进程生成 RDB 文件），然后通过网络传给 Replica。如果数据量大（比如 10GB），这个过程会**消耗大量 CPU、内存和网络带宽**。所以我们的目标是：**尽量避免全量同步，让增量同步成为常态**。
|
||||
> [!QUESTION] 怎么理解"offset 在 backlog 范围内"？
|
||||
> 回到"圆形笔记本"的比喻——backlog 是一个固定大小的环形缓冲区（默认仅 1MB）。Master 不断往里写新命令，写满了就从头覆盖最旧的内容。当 Replica 断线重连时，它报出自己的 offset，Master 检查：
|
||||
>
|
||||
> - 这个 offset 对应的数据**还在 backlog 里**（没被覆盖）→ 只需发送 backlog 中这段数据 → 增量同步
|
||||
> - 这个 offset 对应的数据**已经被覆盖了**（断线太久，backlog 装不下）→ 只能全量同步
|
||||
|
||||
#### PSYNC 完整决策流程
|
||||
|
||||
把上面的逻辑串起来，PSYNC 的完整判断过程如下：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start["Replica 发送<br/>PSYNC <runId> <offset>"] --> CheckRunID{"runId 匹配?"}
|
||||
|
||||
CheckRunID -->|"不匹配<br/>(Master 重启或新 Master)"| FullSync["返回 +FULLRESYNC<br/>全量同步"]
|
||||
|
||||
CheckRunID -->|"匹配"| CheckOffset{"offset 对应的数据<br/>还在 backlog 里?"}
|
||||
|
||||
CheckOffset -->|"是"| PartialSync["返回 +CONTINUE<br/>增量同步"]
|
||||
CheckOffset -->|"否<br/>(已被覆盖)"| FullSync
|
||||
|
||||
CheckRunID -->|"runId = '?'<br/>(首次连接)"| FullSync
|
||||
```
|
||||
|
||||
> [!NOTE] 一句话总结 PSYNC 的决策逻辑
|
||||
> 先看你"认不认识我"（Run ID），再看你"缺的那部分我还记不记得"（Offset 是否在 backlog 内）。两个条件都满足才走增量，否则全量。
|
||||
|
||||
#### 全量同步的代价
|
||||
|
||||
> [!QUESTION] 全量同步开销有多大？
|
||||
> 全量同步需要 Master 执行 `BGSAVE`（fork 子进程生成 RDB 文件），然后通过网络传给 Replica。如果数据量大（比如 10GB），这个过程会**消耗大量 CPU、内存和网络带宽**。更糟糕的是，如果多个 Replica 同时触发全量同步，Master 会被拖垮。
|
||||
>
|
||||
> 所以我们的目标是：**尽量避免全量同步，让增量同步成为常态**。
|
||||
|
||||
#### 什么情况下触发全量同步？
|
||||
|
||||
| 触发条件 | 为什么？ | 能避免吗？ |
|
||||
|---------|------|------|
|
||||
| **首次连接** | Replica 是空的，没有数据也没有 offset，只能全量下载 | ❌ 必然发生 |
|
||||
| **Master 重启** | Master 重启后 Run ID 变了，Replica 认不出"老朋友" | ⚠️ 持久化可缓解（重启后 Run ID 不变） |
|
||||
| **Replica 手动执行 SLAVEOF** | 相当于主动"认新主人"，必须重新来过 | ❌ 手动触发，通常可控 |
|
||||
| **Backlog 溢出** | 断线太久，Master 的"缓冲笔记本"已经翻页覆盖了断线前的内容 | ✅ **增大 `repl-backlog-size`** |
|
||||
| **config-resetstat 执行** | 元数据被重置，offset 信息丢失 | ⚠️ 少用此命令 |
|
||||
| **首次连接** | Replica 是空的，没有 Run ID 也没有 offset，PSYNC 只能发 `? -1` | ❌ 必然发生 |
|
||||
| **Master 重启** | 重启后 Run ID 变了，Replica 发的旧 Run ID 匹配不上 | ⚠️ 持久化可缓解（配置 `save` 后重启 Run ID 不变） |
|
||||
| **Replica 执行 SLAVEOF 指向新 Master** | 新 Master 的 Run ID 和旧的不同，必须全量重来 | ❌ 手动触发，通常可控 |
|
||||
| **Backlog 溢出** | 断线太久，Replica 需要的 offset 已被环形缓冲区覆盖 | ✅ **增大 `repl-backlog-size`** |
|
||||
| **config-resetstat 执行** | 重置 INFO 统计计数器，可能干扰监控判断，但不会直接影响复制 offset | ⚠️ 少用此命令 |
|
||||
|
||||
> [!WARNING] 生产环境最常见的"不必要全量同步"
|
||||
> 绝大多数情况是 **Backlog 过小**导致的。网络抖动几秒，Backlog 不够用，Replica 被迫全量同步——这在网络不稳定的环境中会反复发生，严重拖垮 Master 性能。**加大 Backlog 是性价比最高的优化手段**。
|
||||
> 绝大多数情况是 **Backlog 过小**导致的。网络抖动几秒，Backlog 不够用，Replica 被迫全量同步——这在网络不稳定的环境中会反复发生，严重拖垮 Master 性能。**加大 Backlog 是性价比最高的优化手段**，具体配置和估算方法见下一节。
|
||||
|
||||
### 复制背压（Replication Backlog）
|
||||
|
||||
每个 Master 内部维护一个固定大小的 **环形缓冲区**（默认仅 1MB），这是实现增量同步的关键：
|
||||
每个 Master 内部维护一个固定大小的 **环形缓冲区**（64-bit 系统上默认 1MB，Redis 7.0+ 默认 64MB），这是实现增量同步的关键：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -180,6 +280,69 @@ repl-backlog-ttl 3600 # 无人订阅时多久自动释放（秒）
|
||||
- backlog = 1MB → 约支持 **2 秒** 断线恢复
|
||||
- backlog = 256MB → 约支持 **8 分钟** 断线恢复
|
||||
|
||||
### REPLCONF ACK：Master 如何感知 Replica 状态
|
||||
|
||||
> [!QUESTION] Master 一直在往 Replica 发数据，但它是单向发送的——Master 怎么知道 Replica 是否还活着、同步到哪了？
|
||||
> 前面讲的都是 "Master → Replica" 的数据流。但复制是双向"互动"的：Master 需要知道每个 Replica 的实时状态，才能做运维决策（比如判断延迟、拒绝写入保护数据一致性）。这个感知能力靠的是 **Replica 主动向 Master 汇报**。
|
||||
|
||||
**工作原理**：Replica 每秒向 Master 发送一次 `REPLCONF ACK <offset>` 命令，告诉 Master 两件事：
|
||||
|
||||
1. **"我还活着"** — 心跳保活
|
||||
2. **"我的同步进度是 offset=xxx"** — 用于计算延迟
|
||||
|
||||
Master 收到后更新该 Replica 的状态。通过 `INFO replication` 可以看到：
|
||||
|
||||
```text
|
||||
connected_slaves:3
|
||||
slave0:ip=192.168.1.21,port=6379,state=online,offset=12345600,lag=0
|
||||
slave1:ip=192.168.1.22,port=6379,state=online,offset=12345600,lag=0
|
||||
slave2:ip=192.168.1.23,port=6379,state=online,offset=12344800,lag=2
|
||||
```
|
||||
|
||||
- **offset**：该 Replica 当前同步到哪里了（对比 Master 的 `master_repl_offset` 可知差距）
|
||||
- **lag**：Master 有多久（秒）没收到这个 Replica 的 ACK，lag 越大说明 Replica 越"失联"
|
||||
|
||||
如果 Master 在 `repl-timeout`（默认 60 秒）内没有收到某 Replica 的 ACK，就将其标记为 `state=offline`。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant R as Replica
|
||||
participant M as Master
|
||||
|
||||
Note over M: "Master 持续写入, offset 推进"
|
||||
R->>M: REPLCONF ACK 10000
|
||||
Note left of M: "记录: slave0 offset=10000, lag=0"
|
||||
M->>M: 继续写入, offset 到 10100
|
||||
R->>M: REPLCONF ACK 10050
|
||||
Note left of M: "记录: slave0 offset=10050, lag=1"
|
||||
|
||||
Note over R: "Replica 断线..."
|
||||
Note over M: "repl-timeout(60s) 内没收到 ACK"
|
||||
Note left of M: "标记: slave0 state=offline"
|
||||
```
|
||||
|
||||
> [!NOTE] REPLCONF ACK 的实际意义：写入保护
|
||||
> 这个机制不只是"看看状态"——它直接支撑了**脑裂场景下的写入保护**。配合以下配置：
|
||||
> ```conf
|
||||
> min-replicas-to-write 1 # 至少 1 个 Replica 在线
|
||||
> min-replicas-max-lag 10 # 且 lag 不超过 10 秒
|
||||
> ```
|
||||
> Master 根据 REPLCONF ACK 汇报的 lag 值判断：**在线且低延迟的 Replica 数量不满足条件时，Master 直接拒绝写入**。这样即使 Master 被网络隔离（脑裂），它也不会默默接受写入——因为没有 Replica 能同步这些数据，写入最终会丢失。
|
||||
>
|
||||
> 简单说：**没有 REPLCONF ACK → Master 对 Replica 状态一无所知 → 无法做写入保护 → 脑裂时必然丢数据**。
|
||||
|
||||
> [!QUESTION] REPLCONF ACK 和 Sentinel 的心跳有什么区别？
|
||||
> 两者都是"心跳检测"，但**方向和目的不同**：
|
||||
>
|
||||
> | 对比 | REPLCONF ACK | Sentinel PING |
|
||||
> |------|-------------|---------------|
|
||||
> | 方向 | Replica → Master | Sentinel → Master/Replica |
|
||||
> | 频率 | 每秒 1 次 | 每秒 1 次 |
|
||||
> | 目的 | Master 感知 Replica 存活和同步进度 | Sentinel 感知节点存活，触发故障转移 |
|
||||
> | 判定失联后 | Master 标记 Replica 为 offline，触发 min-replicas 保护 | Sentinel 标记 SDOWN/ODOWN，触发选主和 Failover |
|
||||
>
|
||||
> 两者互补，缺一不可。
|
||||
|
||||
### 大 Key 问题
|
||||
|
||||
> [!QUESTION] 一个 key 有 5MB 大小，会有什么问题？
|
||||
@@ -282,10 +445,15 @@ replica-lazy-flush no # 确保同步前快速清理旧数据
|
||||
|
||||
```conf
|
||||
# 适用于金融、账务等场景
|
||||
WAIT 1 100 # 写入时确认至少 1 个副本成功
|
||||
repl-backlog-size 512mb # 更大缓冲区容纳更多增量命令
|
||||
```
|
||||
|
||||
```go
|
||||
// WAIT 是运行时命令，不能写在 redis.conf 里，需在业务代码中调用
|
||||
// 写入后等待至少 1 个副本确认同步，最多阻塞 100ms
|
||||
client.Do(ctx, "WAIT", 1, 100)
|
||||
```
|
||||
|
||||
### 常用调试命令
|
||||
|
||||
```bash
|
||||
@@ -413,8 +581,8 @@ flowchart TD
|
||||
|
||||
| 优先级 | 评估维度 | 含义 | 举例 |
|
||||
|--------|---------|------|------|
|
||||
| 1（最高） | **复制偏移量最大** | 同步进度最接近 Master | Replica-A offset=10000, Replica-B offset=9998 → 选 A |
|
||||
| 2 | **`replica-priority` 最小** | 配置中人为指定的优先级 | priority=10 优先于 priority=100；priority=0 表示"永不选我" |
|
||||
| 1（最高） | **`replica-priority` 最小** | 配置中人为指定的优先级 | priority=10 优先于 priority=100；priority=0 表示"永不选我" |
|
||||
| 2 | **复制偏移量最大** | 同步进度最接近 Master | Replica-A offset=10000, Replica-B offset=9998 → 选 A |
|
||||
| 3（最低） | **Run ID 字典序最小** | 纯粹的 tie-breaker | 两个 Replica 前两项完全相同，选 Run ID 字母序靠前的 |
|
||||
|
||||
> [!WARNING] 如果所有 Replica 都不健康怎么办？
|
||||
|
||||
Reference in New Issue
Block a user