Redis 单实例很好用，但当数据量、可用性和吞吐上来以后，问题会变成：是加从库，还是上哨兵，还是做分片，还是直接用 Redis Cluster。
这几个词经常混在一起说。实际上它们解决的问题不一样：主从和哨兵主要解决高可用和读扩展，分片主要解决容量和写扩展，Redis Cluster 则把分片、主从和故障转移放进官方集群方案里。
先区分两个问题
第一个问题是高可用：主节点挂了以后，服务能不能自动恢复。
第二个问题是分片：单个 Redis 实例放不下或扛不住时，数据能不能拆到多个主节点上。
只做主从复制，并不等于做了分片。一个主节点加多个从节点，数据通常仍然是完整复制，容量上限主要还是由主节点决定。
只做分片，也不等于自动高可用。如果每个分片只有一个主节点，某个主节点挂了，对应 key 范围仍然不可用。
所以 Redis 架构要先问清楚：当前主要痛点是可用性、读压力、写压力，还是内存容量。
主从复制：读扩展和高可用基础
主从复制的基本过程可以简化成：
- 从节点连接主节点，请求同步。
- 主节点生成快照，并记录同步期间发生的写命令。
- 从节点加载快照。
- 主节点继续把后续写命令同步给从节点。
主从复制的好处是结构简单，可以把部分读请求放到从节点上，也为后续故障切换提供基础。
但主从复制本身不等于自动故障转移。主节点挂了以后，如果没有额外机制，客户端仍然可能连着旧主节点地址，需要人工切换或依赖外部系统更新路由。
另外，主从复制有延迟。对一致性要求高的读请求，不要默认读从库。比如刚写完马上读、余额扣减、幂等状态判断这类场景，要明确读写路径和一致性边界。
哨兵：给主从加自动故障转移
Sentinel 哨兵主要解决主从模式下的自动故障发现和切换。
它会持续监控主节点、从节点和其他哨兵。当主节点长时间无响应，哨兵会先标记主观下线；多个哨兵达成一致后，再标记客观下线，并从从节点里选一个提升为新主节点。
哨兵模式适合：
- 单主数据量还能放下。
- 主要需求是高可用，而不是把数据拆到多个主节点。
- 客户端或连接池能感知哨兵返回的新主地址。
它的边界也很清楚：哨兵不负责把一份大数据拆成多份。所有从节点复制的仍然是同一份主数据。如果单实例内存或写吞吐已经到上限，哨兵不是容量扩展方案。
客户端分片：路由放在业务里
客户端分片指业务代码自己根据 key 计算应该访问哪个 Redis 实例。常见做法是 hash、取模、一致性 hash 或自定义路由表。
它的优点是路径短，少一层代理，性能好，规则完全可控。
但缺点也明显：
- 每个业务都要理解分片规则。
- 扩容缩容要改路由或迁移数据。
- 多语言、多服务共用时，规则一致性难维护。
- 故障处理和监控需要自己补齐。
客户端分片更适合团队对 Redis 使用方式有统一封装，或者业务规模还没大到需要完整集群治理，但已经需要拆容量的场景。
代理分片：路由放在中间层
代理分片是在业务和 Redis 实例之间加一层代理。业务只连代理，代理根据路由规则把请求转发到对应实例。
典型思路是 Twemproxy、Codis 这类中间件。它的好处是业务侧简单，连接治理和迁移流程可以集中到代理层。
代价是多了一跳网络和中间层成本。代理本身也要高可用，否则 Redis 没挂，代理挂了，业务一样会受影响。
代理分片比较适合多业务共享 Redis 能力、希望业务少感知分片细节、并且团队愿意维护一层中间件的场景。
Redis Cluster：官方分片方案
Redis Cluster 是官方集群方案。它把 key 空间划分为 0 到 16383 共 16384 个 hash slot。每个 key 会通过 CRC16 计算落在哪个 slot，再由 slot 映射到具体主节点。
每个主节点负责一部分 slot。为了高可用，每个主节点可以配置一个或多个从节点。主节点故障后，从节点可以被提升为新主节点。
它的优点是：
- 官方方案，生态支持更完整。
- 客户端可以直连节点，不一定需要中心代理。
- 分片和高可用在同一套模型里。
- 数据容量和写压力可以通过增加主分片扩展。
它的限制也要提前知道：
- 客户端必须支持 Cluster 协议和重定向。
- 跨 slot 的多 key 操作有限制。
- 扩容缩容涉及 slot 迁移，不能只加机器不迁数据。
- 键设计要注意 hash tag，否则相关 key 可能分散到不同 slot。
如果业务大量依赖 mget、Lua、多 key 事务或集合间运算，迁到 Cluster 前一定要先盘点这些命令是否跨 slot。
扩容时真正麻烦的是什么
Redis 扩容不是“多起几个实例”这么简单。真正麻烦的是旧数据已经按旧规则分布了，新规则上线后，客户端会把新请求打到新位置，旧数据却还在旧位置。
常见风险包括：
- hash 规则变化导致同一个 key 落点变化。
- 直接复制实例后出现重复数据或热点没有消失。
- 长期不过期的 key 堆积，迁移成本越来越高。
- 迁移期间读写双写、回源和一致性策略没有想清楚。
所以扩容前要先做数据画像：key 数量、内存占用、过期时间、热点 key、命令类型、最大 value、持久化和复制延迟。不要只看 Redis 总内存。
一个实用选型顺序
如果只是想提高读可用性，先考虑主从复制；如果还要自动故障转移，在主从基础上加哨兵。
如果单主容量和写压力已经吃紧，就要进入分片。团队能统一封装客户端、规则简单，可以考虑客户端分片；希望业务少感知，且能维护代理层，可以考虑代理分片。
如果新系统从一开始就需要多主分片、高可用和官方生态支持，Redis Cluster 是更主线的选择。但要提前约束 key 设计和多 key 命令使用方式。
可以粗略记成：
- 主从：解决读扩展和复制基础。
- 哨兵：解决主从自动切换。
- 客户端分片：把容量拆分逻辑放到业务侧。
- 代理分片：把容量拆分逻辑放到中间层。
- Redis Cluster：官方 slot 分片加高可用方案。
小结
Redis 架构不要只按名词选型。先判断当前瓶颈是什么：
- 可用性问题：主从加哨兵。
- 读压力问题：读写分离，但要接受复制延迟。
- 容量问题：分片。
- 写压力问题：多主分片或 Cluster。
- 运维治理问题：优先选团队能长期维护的方案。
Redis 很快，但它不是魔法缓存。分片规则、过期策略、热点 key、复制延迟和迁移流程，才是大多数线上问题真正发生的地方。
