面试结束那天，我没有被当场淘汰，还进了下一轮。下班后站在公司天台吹风时，我知道那晚系统没炸，心里有股说不出的轻松。
那晚的情景先说结果再回头讲过程。事情的关键在于我能把 Redis 主从复制的来龙去脉说清楚，并且把线上遇到的问题和应对办法讲得清楚。面试官点头的次数，比会议室里冷气的档位还多。顺利过了这次技术关，后来还有人问我那晚到底怎么说的，所以把全过程按倒序、按层次梳理给你。
回到面试现场：下午三点，会议室冷气开得很足，我穿着一件薄外套，手里握着简历，感觉有点像被踢出缓存的旧 key。面试官看起来很沉稳，敲了两下桌子就开口要我讲 Redis 集群的主从复制模型，并问我在项目中是怎么用的。那一瞬间脑子有点像重启，先卡壳，接着缓存命令慢慢流出来，最后进入清晰模式。
从大方向说，Redis 在许多线上系统里承担的任务很明确：提升响应，缓解数据库压力，撑起会话、缓存、库存等热点数据场景。想象一个电商站点：首页的商品列表、用户会话、购物车、秒杀库存，全都靠 Redis 支撑。平时流量一般，但到了促销节点，访问会像潮水一样猛冲过来。要保证系统能扛住这种冲击，Redis 的目标就是：高可用、高并发、容易扩展。主从复制正是为此服务的一个常见方案。
把主从复制用通俗的比喻说，就是一个写主节点和若干读从节点。所有写操作统一到主节点执行，主节点再把数据发给从节点备份。从节点主要承担读请求，分散读压力。这个办法能明显提升并发能力和可用性，但也带来一些代价和细节需要注意。
技术细节上，复制过程大致分阶段。第一步是建立连接并请求同步。每当一个从节点启动或重新连接，它会主动去连主节点，告知主节点自己需要同步数据。接下来，如果是第一次连接或者断线时间太久，主节点会走一次完整的同步。这个阶段主节点会把当前数据以快照的形式生成，然后把这份“作业本”交给从节点。这个过程相对耗时，但能保证从节点拿到一份完整的数据快照。
问题在于，主节点在生成快照的同时并不会停下处理新的写请求。如何把这段时间产生的新写同步给从节点？这就牵涉到一个缓冲机制：主节点会把这段时间的写命令暂存在一个复制积压区。快照传完后来，主节点把积压区里的增量命令继续发给从节点，最终从节点追上主节点的写序列。之后进入常态的实时复制模式：主节点每有新写，就会把相应命令推给所有从节点。
还有一个常见场景是从节点短暂失联再连上。这时候系统不必定重新做完整同步。Redis 会尝试进行部分重同步：从节点重连时会报告自己最后同步到的偏移量，主节点查看积压区里有没有那段差值的命令，如果还在，就直接把遗失的增量发回去，完成补齐。能否走部分重同步，和积压区的大小、断线时间、写入速度都有关系。高并发场景下，这块儿设定不合理，很容易从节点重连就被迫全量同步，耗时又耗资源。
在项目实践中，最常见的做法是把读写流量做分离。写流量走主节点，读流量走从节点，前面再加一层负载均衡把读请求分摊到多个从节点上。这样能提高吞吐能力，但有个重大风险：复制是异步的，存在延迟。对于强一致性要求高的场景，列如涉及金额、库存变更的关键操作，必须直接读写主节点，或者引入更强的一致性控制手段。否则会出现读到过期数据的情况，带来业务问题。
面试时，单说优点不够，说出缺点反而更能体现经验。几个明显的问题，包括主节点是单点写入压力的焦点，网络或高负载下主节点同步压力会变大，异步复制会带来数据延迟和一致性隐患。此外，从节点过多时，主节点需要把数据发给更多人，这本身也会占用主节点的资源，影响整体性能。
现场我还用了一段可以直接念出来的标准表述，逻辑清楚、覆盖要点：Redis 的主从复制通过一个主节点和多个从节点完成数据同步。写请求统一到主节点，由主节点以异步方式把更新复制到从节点，从节点承担读请求，实现读写分离，从而提升并发和可用性。复制分为全量与增量两种，同步首次为全量，后续通过复制积压区支持增量同步和部分重同步。该模型存在延迟和主节点压力问题，生产环境一般结合哨兵或 Cluster 做高可用与分片。
最后讲一个真实线上经历补充说服力。我之前在一家做在线直播课的公司，晚高峰有上万人同时抢课。最开始是单机 Redis，QPS 一到就卡住。后来我们把数据分层、做读写分离、加了从节点、调优积压区和负载均衡，那晚抢课峰值来了，系统虽然压力巨大，但没崩。那阵子站在公司天台喘口气的感觉，像是把服务器从危险边缘拉回来了，挺爽的。
我是小米，31岁，从事后端开发，爱把遇到的问题和解决办法写出来。想看更多类似经历可以关注我的公众号：软件求生。
暂无评论内容