我先给你讲个故事。前几年我刚进一家公司，业务涨得特别猛，一开始我们用 Redis 就是很“朴素”的：一个 Redis 实例，所有请求都怼上去。
刚开始很爽，QPS 上千感觉自己是扛着服务器在飞。结果有一天，大促来了。凌晨两点，监控报警。Redis CPU 飙到 90%，延迟肉眼可见地抖，接口 RT 从 30ms 飙到 800ms。
那一刻我就懂了一个真理：
单点 Redis，再强，也终有扛不住的一天。
于是我们开始考虑三个问题：
读请求太多，怎么扛？Redis 挂了，业务怎么办？能不能不停机扩展能力？
这三个问题，刚好对应主从的三个核心价值：
读压力大？分担！
很多业务场景下：
写请求其实很少90% 都是读，比如查询用户信息、商品信息、缓存配置等
如果所有读写都打给一个 Redis，你等于让一个人同时当客服 + 快递 + 会计 + 电工，那不崩才怪。
主从出来的第一目标，就是：
主写，从读，让读分担压力。
害怕单点？提高可用性！
如果 Redis 只有一个节点，只要这个宕了，缓存直接雪崩，数据库跟着遭殃，重则整站崩溃。
主从架构允许你：
主节点挂了从节点还能读后面还能接管
虽然这不是强一致的高可用，但至少不是“一死全死”。
未来涨流量？横向扩！
当业务成长，流量爆炸，你不可能一直升级一台服务器。主从架构就是为水平扩展打基础的第一步。
一主多从，读节点随便加，只要机器顶得住，流量就能顶住。
Redis Replication→ 主从架构 → 读写分离 → 扛住高并发
在面试中，这一串逻辑你一定要能讲出来，而且要讲得像故事一样顺。一句话帮你串起来：
Redis 通过 replication（复制）机制实现主从架构，进而实现读写分离，从而通过扩展从节点来支撑高并发读场景。
拆开聊：
Redis replication：核心就是数据同步机制在此基础上，形成：主从架构进而可以做：读写分离最后达到：通过横向扩展从节点抗住大量读请求
这个逻辑说通了，面试官至少给你 7 分起步。
Redis replication 的核心机制讲清楚
现在我们进入技术区，小米给你拆开讲，不废话堆概念。
Redis replication，说人话就是：
从节点不断“抄作业”主节点。
主节点负责接收写命令，从节点呢，就一直同步主节点的数据，保证自己尽量接近主节点状态。
它的几个核心特性：
1. 异步复制
Redis 的主从复制是异步的，也就是说：
主节点写成功就返回客户端不会等从节点同步完成
好处是：性能好坏处是：可能存在短暂数据不一致
但是大多数缓存场景是可以接受的。
2. 全量 + 增量 两种复制方式
Redis 的复制分为两种：
2.1、全量复制
第一次建立主从时，从节点需要完整同步主节点所有数据。步骤是：
从节点发送 PSYNC 或 SYNC主节点创建 RDB 快照把快照发送给从节点从节点加载 RDB主节点再发送后续产生的新写操作
这是一次比较“重”的操作，很消耗主节点资源。
2.2、增量复制
后续如果连接中断、网络闪断，只需要同步中断期间的命令增量，这就是增量复制。
要不要全量，看你有没有同步中断期间的“复制偏移量”。
3. 复制偏移量和复制积压缓冲区
这里是面试高频点。Redis 内部维护着一个东西：复制积压缓冲区（replication backlog）
里面保存着最近的一部分写命令。从节点断线重连后，会带着它上次同步到的“偏移量”回来。如果主节点 backlog 里还保存着那段数据，就可以进行增量同步。否则，只能重新来一波全量复制。
Redis 主从架构的核心原理
主从关系怎么建立？核心就靠一句配置：
replicaof <master_ip> <master_port>
从节点启动后，会主动向主节点发起复制请求。然后就是主从建立的大致流程：
从节点连接主节点发送 PSYNC 命令主节点判断是全量还是增量同步开始数据同步后续保持心跳 + 命令流同步
同步完成后，从节点就进入“在线同步”状态，主节点每写一条命令，都会推给从节点。
这一点你可以类比为：
主节点在直播，从节点在实时跟播。
Redis 主从复制过程原理（详细版）
我们用一个场景串起来讲。假设你新建了一个从节点 slave1：
第一步：建立连接
slave1 启动后，主动连接 master，发送同步请求。
第二步：判断复制方式
master 根据 slave1 提供的信息判断：
是断线重连？→走增量是新来的？→走全量
第三步：执行全量复制
如果是全量复制：
master 开始执行 BGSAVE，生成 RDB同时把新的写命令先缓存到 replication bufferRDB 生成完，发送给 slaveslave 加载 RDB 数据master 把刚才缓存的写命令发送给 slave
第四步：进入命令复制阶段
之后每当 master 执行写命令：
一方面写入本地一方面异步推给所有从节点
从节点接收到命令后，按顺序执行，完成数据同步。
到这里，一个完整的主从复制链路就跑起来了。
你在面试时，可以用一个词总结：命令传播模型
Redis 主从架构的缺点（别只吹优点！）
真正能让面试官点头的，是你能讲清楚缺点。因为很多人只会背“它好牛逼”，却讲不清“它哪里不行”。我给你总结几个硬伤：
1. 主库压力大
所有写请求都集中在主节点，写多的场景下，主节点压力会非常大。主从架构只能扩展读能力，写是没法横向扩展的。
2. 数据是“最终一致”
由于是异步复制，从节点的数据一定有延迟。如果业务对强一致性要求极高，Redis 主从并不适合做核心存储。
3. 存在数据丢失风险
在以下场景下可能出现数据丢失：
主节点宕机，部分数据还没同步到从节点从节点刚同步完，主库又炸了
这部分数据就直接“消失”了。
4. 不具备自动故障转移能力
原生 Redis 主从是不带自动故障转移的。如果主挂了，需要手动切换，或者借助：
Redis SentinelRedis Cluster
单靠主从复制，是不够高可用的。
5. 扩展写能力有限
主从架构只能靠一个主节点写，你写流量上来后，很容易遇到天花板。这也是 Redis Cluster 存在的意义之一。
帮你总结一套面试话术
如果你在面试中被问：“说说 Redis 主从架构？”
你可以这么回答（自己按场景调整用词）：
Redis 主从架构主要是通过 replication 机制实现的。
主节点负责处理写请求，同时将写命令异步同步给多个从节点，从节点主要承担读请求，从而实现读写分离，提升系统整体吞吐能力。
在复制机制上，Redis 采用了全量复制和增量复制相结合的方式，通过复制偏移量和复制积压缓冲区来减少不必要的全量同步。
不过主从架构本身也有一些局限，比如主节点写压力集中、数据只能保证最终一致、存在一定的数据丢失风险，而且本身不具备自动故障转移能力，需要结合 Sentinel 或 Cluster 才能实现高可用和高扩展。
说完这段，基本面试官都会点头。
END
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...