有一次，我去参加一个大厂社招面试。
下午三点，会议室冷气开得像北极，我穿着优衣库薄外套，手里捏着简历，感觉像刚被从 Redis 缓存里淘汰出来的过期 key。
面试官很稳重，敲了两下桌子，开口问了第一句：
“来，说说 Redis 集群的主从复制模型，你在项目里怎么用的？”
那一瞬间，我的脑子像 Redis 重启，先冷、再热、最后进入高性能模式。
今天，就把我当时脑内风暴 + 实战经验 + 面试教训，原封不动讲给你听。
先讲故事：为什么 Redis 要搞主从复制？
你想象一下。
你现在在做一个电商系统，首页商品列表、购物车、秒杀库存、用户会话，全压在 Redis 上。白天没事，晚上双十一，流量像丧尸一样往你服务器冲过来。
如果你只有一个 Redis：
- 它一挂，全站卡成 PPT。
- 它一慢，用户直接走人。
- 它一被打爆，你老板直接打爆你。
所以，Redis 的第一个目标：高可用 + 高并发 + 可扩展
这时候，主从复制模型就登场了。
Redis 主从复制模型，本质是什么？
用人话讲就是一句话：
一个 Redis 主节点（Master），多个 Redis 从节点（Slave），主负责写，从负责读，主把数据同步给从。
你可以把它想成一个“班主任 + 答题小组”模型。
- 班主任：负责批改、发题（写操作）
- 小组成员：负责帮忙答题（读操作）
所有作业先交给班主任，再由班主任分发给每个小组成员备份。这样：
- 一个节点挂了，还有别的节点顶上
- 读压力被分摊
- 系统整体性能上去
Redis 主从复制的核心目标
这个模型，主要解决三件事：
- 读写分离：写在 Master，读在 Slave，降低单节点压力
- 数据备份：Slave 是一份实时备份，Master 宕机也能救命
- 高可用基础：为后续哨兵模式和 Redis Cluster 做铺垫
主从复制是怎么“复制”的？
面试官特别爱问：“你说主从复制没问题，那 Redis 是怎么同步数据的？”
这个时候，你要拆成三个阶段讲，面试官会疯狂点头。
第一阶段：建立连接 & 发送同步请求
当你启动一个 Slave，
- 并配置：replicaof 192.168.1.10 6379
- 或者旧版本是：slaveof 192.168.1.10 6379
它会主动去连 Master：
- 建立 TCP 连接
- 发送 PSYNC 命令，表示：我要同步你的数据
第二阶段：全量复制（Full Sync）
如果是第一次连，或者断线时间太久：
Master 会：
- fork 一个子进程
- 把当前数据库数据生成 RDB 快照
- 把这个 RDB 文件发送给 Slave
- Slave 清空自己旧数据，然后加载这个新 RDB
这个过程叫：全量复制
这个过程时间比较长，但是是绝对完整的。你可以理解为：
班主任把一整本作业册子，重新复印发给你。
第三阶段：增量复制（Incremental Sync）
关键来了。
在生成 RDB 过程中，Master 并不会停，它还在处理新的写请求。
这时怎么办？Redis 设计了一个东西：复制积压缓冲区（Replication Backlog Buffer）
Master 会把新增的写命令记录下来，RDB 发送完后，再把这部分增量数据发送给 Slave。之后，进入实时状态：Master 每写一条命令，就立刻同步给所有 Slave。
这阶段就叫：增量复制
断线重连：部分复制机制
面试官还有一个很阴险的问题：
“如果 Slave 网络抖动，断了一会再连，Redis 会重新全量同步吗？”
标准答案：
不一定，会优先尝试部分重同步（Partial Resync）
Redis 会维护一个：
- replication offset（复制偏移量）
- backlog buffer
Slave 重连后，会告诉 Master 自己同步到哪里了。如果 backlog 里还保留着这部分数据：
- 那就增量补上
- 如果被覆盖没了，只能全量同步
所以在大流量场景中，backlog buffer 的大小很关键！
从读写分离角度看主从模型
你的项目中，最常见用法一定是：
- 写：走 Master
- 读：走 Slave
你可以这样跟面试官说一句非常加分的话：
“我们线上通过中间件实现读写分离，写流量走 Master，查询流量走从节点，通过负载均衡分摊读压力，提升吞吐能力。”
特别加分。但你也要说风险：数据延迟问题
因为复制是异步的：
- Master 写成功了
- Slave 可能还没同步到
- 这时候读从节点，可能读到旧数据
所以，对强一致性场景（比如金额、库存）：我们会强制走 Master
一个典型的主从复制架构
给你一个你可以在面试现场用嘴画出来的场景：
你在面试现场配合手势，这图基本能在面试官脑中浮现。
主从复制的优点
总结给你几个面试用点：
- 支持读写分离，提升吞吐量
- 提供数据备份能力
- 支撑高可用架构（哨兵/集群基础）
- 多从节点可横向扩展读能力
主从复制的局限和问题
真正有经验的人，不能只说优点，还要敢说问题。你可以说几点缺陷：
1. 主节点单点问题
- 如果只有主从复制，没有哨兵：Master 挂了，系统就废了。
- 所以生产环境一般都会搭配：Redis Sentinel（哨兵模式），实现自动故障转移。
2. 数据一致性问题
因为是异步复制：
- 可能丢失少量数据
- 强一致性无法保证
所以：
- 金融类、强一致要求场景要谨慎
- 有时要走双写或强制主节点
3. 网络和性能压力
主节点要给多个从节点同步数据：
- 从节点越多
- 主节点压力越大
高并发场景下，有可能反而拖慢主节点。
面试实战高分回答模板（你可以直接背）
给你一版我当年整理的“标准面试答案”，你可以直接口述出来：
Redis 的主从复制模型是通过一个 Master 节点和多个 Slave 节点来实现数据同步。写请求统一走 Master 节点，由 Master 异步将数据复制到所有 Slave，从节点主要承担读请求，实现读写分离，提高系统的并发能力和可用性。
主从复制分为全量复制和增量复制，第一次连接为全量同步，后续通过 replication backlog 实现增量同步，并支持断线后的部分重同步。同时，这种模型也存在数据延迟和主节点单点问题，因此在生产中通常会结合 Redis 哨兵或 Redis Cluster 架构一起使用。
这段话，我面过 5 家，一说出来，对方基本点头。
真实经验
最后跟你说个真实场景。
我之前在一个教育行业做直播课项目，晚上上万人抢课，Redis QPS 直接飙爆。刚开始只有单机，后来直接：
- 加主从
- 做读写分离
- 导入哨兵
- 最后升级 Cluster
那天晚上系统没炸，我站在公司天台吹风，觉得自己像救过一次服务器的命。那种爽，不是发工资能比的。
END
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
