当前位置：首页 > news >正文

Redis 主从复制：银行 “总公司与分公司” 的业务同步逻辑

news 2025/9/6 8:48:34

一、主从复制的核心逻辑：“先抄全本，再跟新单”

1. 同步（首次 / 断线重连补全量）

2. 命令传播（日常实时同步）

二、智能同步：PSYNC 的 “全量补档” 与 “增量补单”

实现 “智能补漏” 的三个关键：像分公司的 “同步三工具”

1. 复制偏移量：“业务同步进度条”

2. 复制积压缓冲区：“总公司的近期交易备份夹”

3. 服务器运行 ID：“总公司的营业执照号”

三、分公司连接总公司的 7 步流程：从 “申请合作” 到 “实时同步”

步骤 1：确定总公司地址（设置主服务器信息）

步骤 2：打通专线（建立套接字连接）

步骤 3：测试专线（发送 PING 命令）

步骤 4：验证身份（身份验证）

步骤 5：告诉总公司自己的联系方式（发送端口信息）

步骤 6：同步数据（执行 PSYNC 命令）

步骤 7：实时同步（命令传播）

四、衔接之前的 Redis 知识：同步逻辑的 “底层支撑”

五、总结：主从复制的 “银行同步哲学”

如果把 Redis 想象成 “Redis 银行”，那么主服务器（master） 就是银行的总公司（比如总部网点，端口 6379），从服务器（slave） 就是银行的分公司（比如郊区网点）。分公司需要实时同步总公司的客户账户、交易记录（对应 Redis 的键值对数据），确保客户去任何网点都能查到正确信息 —— 这就是主从复制的核心目的：数据一致性 + 服务高可用。

一、主从复制的核心逻辑：“先抄全本，再跟新单”

分公司和总公司的同步分两步，对应 Redis 的 “同步” 和 “命令传播”：

1. 同步（首次 / 断线重连补全量）

首次同步：新成立的分公司，没有任何业务数据，需要从总公司拿 “完整业务档案（全量数据）”。总公司会生成一份 “全量档案（RDB 文件）”，发给分公司；分公司拿到后，先清空自己的旧档案，再照着全量档案还原数据（对应 Redis 首次复制时，主服务器执行BGSAVE生成 RDB，发给从服务器载入）。
断线重连同步：分公司突然断网 10 分钟，期间总公司有新交易。重连后分公司会问总公司：“我断网期间漏了哪些交易？”
- 如果漏的交易还在总公司的 “近期交易备份夹” 里（复制积压缓冲区），就只补这些漏的（部分重同步）；
- 如果漏的太多，备份夹里没有了，就只能再要一次 “全量档案”（完整重同步）。

2. 命令传播（日常实时同步）

分公司拿到全量档案后，后续总公司的每一笔新交易（比如 “客户 A 存款 100 元”，对应 Redis 的SET user:A 100），都会实时发给分公司 —— 分公司只要执行这些 “交易指令”，就能保持数据和总公司一致（对应 Redis 主服务器将写命令传播给从服务器）。

二、智能同步：PSYNC 的 “全量补档” 与 “增量补单”

分公司重连时，怎么判断该要 “全量档案” 还是 “漏单”？靠 Redis 的PSYNC命令，它有两种模式：

`PSYNC`模式	银行场景类比	适用场景
完整重同步	分公司要 “全量业务档案”	新分公司首次同步、分公司断线太久漏单超备份
部分重同步	分公司只补 “断网期间的漏单”	分公司断线时间短，漏单还在总公司备份里

实现 “智能补漏” 的三个关键：像分公司的 “同步三工具”

要实现部分重同步，总公司和分公司需要三个 “同步工具”，缺一不可：

1. 复制偏移量：“业务同步进度条”

总公司和分公司各有一个 “进度条”（偏移量，单位：字节）：
- 总公司每发 100 字节的交易数据（比如一条SET命令的协议内容），自己的进度条就 + 100；
- 分公司每收到 100 字节，自己的进度条也 + 100。
分公司重连时会说：“我的进度条到 1000 了，你呢？” 总公司如果进度条是 1200，就知道分公司漏了 200 字节的数据（对应 2 笔交易）。

2. 复制积压缓冲区：“总公司的近期交易备份夹”

总公司有个 “固定大小的备份夹”（默认 1MB，对应repl-backlog-size），每发一笔交易给分公司，就同时把交易 “复印一份” 放进备份夹（FIFO 队列，满了就删 oldest 的）。
分公司漏单时，总公司会查备份夹：如果漏的 200 字节还在备份里，就直接抽出来发给分公司（部分重同步）；如果不在了，就只能给全量档案（完整重同步）。
备份夹大小怎么算？比如总公司每秒产生 1MB 交易数据，分公司断网平均 5 秒能重连，那备份夹至少要 5MB（公式：秒数×每秒数据量），安全起见设 10MB（2 倍）。

3. 服务器运行 ID：“总公司的营业执照号”

每个 Redis 服务器（总 / 分公司）启动时，会生成一个唯一的 “营业执照号”（40 位十六进制，比如53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3）。
分公司首次同步时，会记下总公司的 “营业执照号”；重连时先核对：如果对方还是原来的总公司（ID 一致），就尝试补漏单；如果是新的总公司（比如原总公司倒闭，换了新总部），就必须要全量档案（因为新总公司的业务数据和旧的不一样）。

三、分公司连接总公司的 7 步流程：从 “申请合作” 到 “实时同步”

新分公司要和总公司同步，需要走 7 个标准步骤，对应 Redis 从服务器执行SLAVEOF后的操作：

步骤 1：确定总公司地址（设置主服务器信息）

分公司负责人执行 “合作申请”：“我们要同步总公司（127.0.0.1:6379）的业务”（对应客户端发送SLAVEOF 127.0.0.1 6379）。

分公司会把总公司的 IP 和端口记在 “合作档案” 里（Redis 从服务器的masterhost和masterport属性），然后回复 “申请已接收”（OK），实际同步后续开始。

步骤 2：打通专线（建立套接字连接）

分公司和总公司之间拉一条 “业务专线”（从服务器创建连向主服务器的套接字）。此时分公司变成总公司的 “合作客户端”（对应 Redis 从服务器成为主服务器的客户端，主服务器会把分公司加入clients链表）。

步骤 3：测试专线（发送 PING 命令）

分公司先给总公司发 “测试信号”（PING命令），确认两件事：

专线通不通（套接字读写正常）；
总公司能不能处理请求（主服务器是否正常）。
结果：通了且总公司回复 “PONG”，继续；不通或报错，就断开重连。

步骤 4：验证身份（身份验证）

如果总公司要求 “合作授权码”（主服务器设了requirepass），分公司就要出示 “授权码”（从服务器设masterauth，发送AUTH命令）：

授权码对了：继续；
对不上或没出示：总公司拒绝合作，分公司重连。

步骤 5：告诉总公司自己的联系方式（发送端口信息）

分公司告诉总公司：“我们的业务电话是 6380（从服务器端口），有问题打这个号”（发送REPLCONF listening-port 6380）。

总公司会把这个端口记在分公司的 “合作档案” 里（主服务器客户端状态的slave_listening_port属性）。

步骤 6：同步数据（执行 PSYNC 命令）

分公司正式请求同步：“请给我业务数据（PSYNC）”。

如果是首次同步：总公司生成 “全量业务档案（RDB 文件）”，发给分公司；分公司载入 RDB 后，总公司再把生成 RDB 期间的 “临时交易”（存在主服务器缓冲区）发给分公司（完整重同步）。
如果是断线重连：分公司报自己的进度条和总公司 ID，总公司核对后，要么发漏单（部分重同步），要么发全量档案（完整重同步）。
此时，总公司也会变成分公司的 “客户端”（方便后续发实时交易）。

步骤 7：实时同步（命令传播）

同步完成后，进入日常 “实时跟单” 阶段：

总公司每有一笔新交易，就实时把 “交易指令” 发给分公司（主服务器传播写命令）；
分公司每秒给总公司发一次 “进度汇报”：“我同步到进度条 1200 了（REPLCONF ACK 1200）”。

这个 “进度汇报” 有三个用：

查专线：总公司 1 秒没收到汇报，就知道专线可能断了；
控风险：如果总公司要求 “至少 3 个分公司同步正常才允许大额交易”（min-slaves-to-write 3），没达标就拒绝写命令；
补漏单：如果总公司发现分公司的进度条比自己慢（比如总公司 1300，分公司 1200），就从备份夹里抽 100 字节的漏单发给分公司。

四、衔接之前的 Redis 知识：同步逻辑的 “底层支撑”

主从复制的实现，离不开之前学过的核心结构：

RDB 持久化：完整重同步时，主服务器用BGSAVE生成 RDB 文件（对应总公司生成全量档案），复用了 RDB 的 “全量备份” 能力；
客户端结构：从服务器是主服务器的客户端（分公司是总公司的合作客户端），主服务器用clients链表管理所有从服务器，复用了客户端的连接管理逻辑；
命令协议：命令传播时，主服务器发送的是 “Redis 协议格式的写命令”（比如SET user:A 100），复用了 Redis 的 “命令序列化” 能力；
内存数据库：同步的本质是 “复制主服务器的内存数据状态”，分公司载入 RDB 后，数据也存在内存中，和 Redis “内存优先” 的设计一致。