Redis 常见使用方式与架构选型
本文主要分析 Redis 几种常见的部署模式及其优缺点，帮助你在实际业务中做出更合适的技术选型。
一、单节点模式
采用单个 Redis 节点部署，没有备用节点实时同步数据，也不提供内置的数据持久化或备份策略。这种架构适用于对数据可靠性要求不高的纯缓存场景。
优势：
- 架构简单：部署和维护都非常方便。
- 高性价比：无需额外备用节点，单实例可用性可通过 Supervisor 等工具保障；若追求更高可用，可牺牲一个备用节点，但同一时刻仍只有一个实例对外服务。
- 高性能：在简单场景下性能表现优异。
局限：
- 数据可靠性低：进程重启后数据可能丢失，即使有备用节点解决了高可用问题，也无法解决缓存预热带来的流量冲击。
- 性能瓶颈：受限于单核 CPU 处理能力（核心命令处理为单线程），CPU 是主要瓶颈。适合操作命令简单、排序和计算较少的场景，复杂场景建议考虑 Memcached 替代。
二、主从复制架构
采用主从（Replication）部署结构，主从实例间数据实时同步，并提供数据持久化和备份策略。主从通常部署在不同物理服务器上，可根据环境配置实现读写分离。
优势：
- 高可靠性：双机主备架构在主库故障时能自动切换，从库提升为主库提供服务；开启持久化功能配合合理备份策略，能有效应对误操作和数据异常丢失。
- 读写分离：从节点可扩展读能力，有效应对大并发量的读请求。
局限：
- 故障恢复复杂：若无 RedisHA 系统支持，主库故障时需手动将某个从节点晋升为主节点，通知业务方变更配置并让其他从库重新同步，人为干预繁琐。
- 写能力受限：主库写能力受单机限制，需考虑分片。
- 存储能力受限：主库存储受单机限制，极端情况下可考虑 Pika 等方案。
- 原生复制弊端：早期版本中，复制中断后 Slave 发起 psync，若同步失败则全量同步。主库执行全量备份可能导致毫秒级卡顿，COW 机制甚至引发内存溢出。生成备份文件会消耗磁盘 IO 和 CPU（压缩）资源，发送 GB 级文件可能阻塞带宽。建议升级到最新版本以优化。
三、哨兵模式 (Sentinel)
Redis Sentinel 是社区推出的原生高可用解决方案，由 Sentinel 集群和 Redis 数据集群组成。Sentinel 集群负责故障发现、自动转移、配置中心和客户端通知，节点数量需满足 2n+1（n>=1）的奇数原则。
优势：
- 部署相对简单：相比主从模式，能解决高可用切换问题。
- 线性扩展：轻松突破单线程瓶颈，满足大容量或高性能需求。
- 灵活监控：一套 Sentinel 可监控一组或多组数据节点。
局限：
- 原理理解繁琐：部署复杂度高于主从模式。
- 资源浪费：Slave 节点作为备份不提供服务。
- 判定逻辑：主要针对主节点的高可用切换，从节点仅做主观下线判定，不执行故障转移。
- 读写分离难：原生不支持，实现起来相对复杂。
建议：
- 监控同一业务时，可选择一套 Sentinel 集群监控多组节点；反之则一对一监控。
sentinel monitor配置建议设为 Sentinel 节点的一半加 1。多 IDC 部署时，单个 IDC 的 Sentinel 数量不建议超过（Sentinel 总数 – quorum）。
