小红书面试总结-Redis部署与实战选型

做后端/中间件的同学，Redis架构选型绝对是高频考点+工作难点！整理了Redis四大核心部署架构的关键对比，结合小红书真实业务场景拆解选型逻辑，干货满满，欢迎评论区交流你的实战经验～ 先快速梳理四大架构核心差异（精准避坑）： 1. 单实例部署：最基础款，仅1个Redis实例，部署简单、资源消耗低，但有致命单点故障，仅适合开发测试、轻量缓存场景，生产环境坚决不推荐！ 2. 主从复制架构：一主多从，主节点写、从节点读，实现读写分离和数据冗余，是高可用架构的基础。但无自动故障转移，主节点宕机需人工切换，写性能受单主限制，适合读多写少、对故障恢复时间要求不高的场景。 3. 哨兵模式：主从架构+3个以上哨兵节点，哨兵实时监控节点状态，主节点故障时10-30秒自动完成故障转移，解决了单主单点问题。运维难度中等，仍有单主写瓶颈，适合中等规模、对高可用有要求、数据量适中（单主≤10GB）的场景。 4. 集群模式（Redis Cluster）：去中心化设计，3主3从起步，16384个哈希槽分片存储，多主并行处理写请求，实现水平扩展，突破单机内存限制，内置自动故障转移。架构复杂、运维难度高，但能承载高并发、海量数据，适合大规模生产、高并发读写、TB级数据存储场景。 重点看小红书实战选型（最具参考价值）： 热门贴缓存场景（读多写少）：选哨兵模式（1主3从+3哨兵）。主节点32GB内存+8核CPU负责写，3个从节点分担读压力，哨兵独立部署保障自动故障转移；配合CDN缓存静态资源，Redis启用LRU淘汰策略，完美匹配百万级阅读量、低写频的业务特点。 热点商品抢购场景（高并发写）：选集群模式。3主3从部署，商品ID作为分片键分散热点，多主分担写压力；结合分布式锁+Lua脚本保证库存扣减原子性，避免超卖，消息队列异步落库保障数据最终一致，支撑秒杀场景每秒数万请求。 补充：TB级海量数据（如用户画像），可选用Sentinel+Cluster混合架构，双重保障高可用和扩展性，但需专业运维团队支撑。 选型核心原则：贴合业务读写特征、数据量和一致性要求，平衡性能、可用性与运维成本。不用盲目追求复杂架构，适合自己业务的才是最好的！ 你们公司生产环境用的哪种Redis架构？遇到过哪些坑？评论区聊聊～