Redis主从复制面试版 - 说人话一、面试场景直接背1. “主从延迟多少算正常”面试官想听不要只说数字要结合业务场景小坏回答这个得看业务能忍多久比如查个商品详情慢个500ms用户可能都感觉不到但要是抢购库存延迟1ms都可能超卖一般来说✅ 几十毫秒优秀✅ 几百毫秒大部分业务能接受⚠️ 超过1秒就得赶紧查了肯定有问题2. “延迟太大怎么办”面试官想听排查思路不是简单答案小坏回答我一般三连问先问网络主从是不是跨了半个地球再看配置缓冲区是不是就1MB默认值太小了最后看性能从节点是不是快卡死了真实案例上次我们延迟3秒发现是有人批量导了100万条数据把从节点CPU打满了。3. “复制缓冲区满了会怎样”面试官想听理解缓冲区的作用小坏回答简单说就是从节点断线重连后要全量复制了。相当于你玩游戏存档丢了得从头开始打。全量复制很要命主节点要生成整个RDB文件网络传这个大文件从节点清空数据重新加载这段时间从节点基本不可用。二、复制原理简单版全量复制 - “笨办法”从节点大哥我新来的全给我吧 主节点好嘞等我把所有数据打包成RDB文件 [传文件...等半天...] 从节点收到了开始慢慢加载...缺点慢、占资源、期间从节点不可读增量复制 - “聪明办法”从节点大哥我刚掉线了这是我最后收到的位置 主节点我看看...哦这个位置的数据还在我缓冲区里 主节点给这是你漏掉的那几条命令关键缓冲区要足够大能存下掉线期间的数据三、监控优化实操经验1. 怎么看延迟# 一句话搞定redis-cli info replication|greplaglag0完美同步lag1延迟1秒lag5老板要骂人了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系统高可用分区容忍弱一致性最后一句“主从复制就像婚姻需要双方共同努力维护。配置调好了是幸福调不好就是互相折磨。”