Redis主从复制（面试版 - 说人话）
Redis主从复制（面试版 - 说人话）
一、面试场景（直接背）
1. “主从延迟多少算正常？”
面试官想听：不要只说数字，要结合业务场景
小坏回答：
"这个得看业务能忍多久：
- 比如查个商品详情，慢个500ms用户可能都感觉不到
- 但要是抢购库存，延迟1ms都可能超卖
一般来说：
✅ 几十毫秒：优秀
✅ 几百毫秒：大部分业务能接受
⚠️ 超过1秒：就得赶紧查了，肯定有问题"
2. “延迟太大怎么办？”
面试官想听：排查思路，不是简单答案
小坏回答：
"我一般三连问：
- 先问网络：主从是不是跨了半个地球？
- 再看配置：缓冲区是不是就1MB默认值？（太小了）
- 最后看性能：从节点是不是快卡死了？
真实案例：上次我们延迟3秒，发现是有人批量导了100万条数据，把从节点CPU打满了。"
3. “复制缓冲区满了会怎样？”
面试官想听：理解缓冲区的作用
小坏回答：
"简单说就是：从节点断线重连后，要全量复制了。
相当于你玩游戏存档丢了，得从头开始打。全量复制很要命：
- 主节点要生成整个RDB文件
- 网络传这个大文件
- 从节点清空数据重新加载
这段时间从节点基本不可用。"
二、复制原理（简单版）
全量复制 - “笨办法”
从节点："大哥，我新来的，全给我吧！" 主节点："好嘞，等我把所有数据打包成RDB文件" [传文件...等半天...] 从节点："收到了，开始慢慢加载..."缺点：慢、占资源、期间从节点不可读
增量复制 - “聪明办法”
从节点："大哥，我刚掉线了，这是我最后收到的位置" 主节点："我看看...哦，这个位置的数据还在我缓冲区里" 主节点："给，这是你漏掉的那几条命令"关键：缓冲区要足够大，能存下掉线期间的数据
三、监控优化（实操经验）
1. 怎么看延迟？
# 一句话搞定redis-cli info replication|grep"lag"lag=0：完美同步lag=1：延迟1秒lag=5：老板要骂人了
2. 怎么调优？
记住3个参数：
# 最重要的：缓冲区大小（默认1MB太小了！） repl-backlog-size 256mb # 连接超时时间 repl-timeout 60 # 从节点输出缓冲区（防从节点处理慢把主节点拖死） client-output-buffer-limit slave 512mb 128mb 60四、面试陷阱题
1. “主从同步是同步还是异步？”
陷阱：直接答"异步"就掉坑里了
小坏回答：
"默认是异步，但也支持同步等。
区别就像：
- 异步：我发微信给你，发完我就不管了（性能好）
- 同步：我当面给你说，等你点头了我才走（一致性好）
Redis支持WAIT命令，可以等从节点确认后才返回。但说实话，生产环境很少用，因为等太久影响性能。"
2. “怎么保证强一致性？”
陷阱：Redis天生就不是强一致的！
小坏回答：
"实话实说，Redis主从保证不了绝对强一致。
但我们可以尽量接近：
- 读写策略：重要数据（如余额）只读主节点，不重要数据（如用户昵称）可以读从节点
- 等待确认：关键操作用
WAIT命令等从节点同步 - 业务补偿：比如扣库存，先扣再查，发现不一致就回滚
说句大实话：真要强一致，就别用Redis主从，用Redis Cluster或者换数据库。"
五、生产环境大实话
部署建议（血泪教训）
- 别用默认配置：那个1MB缓冲区简直是灾难
- 主从别离太远：跨机房延迟至少几十毫秒
- 监控必须做：等用户投诉就晚了
- 备胎要多：至少2个从节点，挂一个还有替补
常见坑爹场景
- 大Key写入：一个10MB的key，从节点能卡好几秒
- 带宽跑满：复制把网卡打满了，业务请求进不来
- 从节点配置低：主节点i7，从节点i3，能不慢吗？
终极建议
“如果业务对一致性要求特别高，考虑别的方案吧。Redis主从适合：能容忍一点点延迟，但要求高性能高可用的场景。”
面试加分项：
- 能说出具体参数值（如
repl-backlog-size默认1MB） - 有真实故障排查经历
- 知道WAIT命令但也能说出它的性能问题
- 理解CAP理论：Redis主从是AP系统（高可用+分区容忍，弱一致性）
最后一句：“主从复制就像婚姻，需要双方共同努力维护。配置调好了是幸福，调不好就是互相折磨。”