redis的集群模式有哪些

开场个人观察

Redis 一开始通常是从单机用起的：缓存商品详情、存登录 token、做计数器、做分布式锁。等系统访问量上来以后，问题就来了：单机内存不够怎么办？主节点挂了怎么办？读压力太高怎么办？业务需要更高可用时怎么做？

这时就要考虑 Redis 的集群模式。这里的“集群”不只是 Redis Cluster 一种，而是一组部署方式：主从复制、哨兵模式、Redis Cluster、代理分片，以及云托管 Redis。每种方式解决的问题不一样，优缺点也不一样。

项目选型时不要先问“哪种最先进”，而要先问：我的数据量有多大？QPS 有多高？能不能接受短暂不可用？团队有没有 Redis 运维经验？业务是否依赖跨 key 操作？

Redis集群模式选型流程

核心观点

Redis 常见部署方式可以按能力逐层理解。

单机模式最简单，适合开发环境、小系统、低风险缓存。但单点故障明显，内存和吞吐也受单机限制。

主从复制解决的是读扩展和数据备份。主节点负责写，从节点复制数据，可以承担部分读请求。但主节点挂了以后，是否自动切换取决于外部机制。

哨兵模式解决的是高可用。Sentinel 会监控主从节点，主节点异常时自动选举新的主节点，并通知客户端切换。它适合数据量还没有大到必须分片，但又需要自动故障转移的系统。

Redis Cluster 解决的是水平扩展。它把 key 映射到 16384 个 hash slot，再把 slot 分布到多个主节点上。容量和吞吐可以通过增加节点扩展，但客户端、跨 slot 操作和运维复杂度都会提高。

代理分片和云托管 Redis 解决的是工程复杂度。代理可以屏蔽后端分片，云托管可以减少运维成本。但要关注命令兼容性、网络延迟、成本和故障透明度。

实践方法

如果是一个普通后台系统，Redis 只用来缓存字典、商品详情、用户权限，数据量不大，故障后可以短暂回源数据库，那么主从或哨兵模式通常就够了。

例如 ERP 系统里，商品基础资料、供应商列表、组织架构权限可以放 Redis 缓存。即使 Redis 短暂不可用，也可以降级查数据库，只是慢一点。这种场景不一定要上 Redis Cluster。

如果系统对可用性要求高，但数据量还在单机内存范围内，可以选择 Sentinel。比如登录 token、会话信息、限流计数这类数据，业务希望节点故障后能自动切换，哨兵模式就比较合适。

如果数据量和访问量都明显增长，比如电商商品缓存、库存热点、活动库存、推荐结果缓存，单机内存和 QPS 已经吃紧，就要考虑 Redis Cluster。Cluster 的好处是容量可以横向扩展，坏处是开发要注意 hash slot。

比如下面这种多 key 操作：

1
MGET product:1001 product:1002 product:1003

在 Cluster 下，如果这些 key 落在不同 slot，可能无法像单机那样直接执行。可以通过 hash tag 把相关 key 放到同一个 slot：

1
2
stock:{sku1001}:available
stock:{sku1001}:locked

但 hash tag 也不能乱用。如果所有 key 都强行放到一个 slot，分片就失去意义。

如果团队 Redis 运维能力弱，又不想自己处理扩容、备份、故障切换，可以考虑云托管 Redis。云服务能减少大量运维工作，但成本、规格限制、网络链路、版本兼容要提前评估。

我做选型时一般按这个顺序问：

  1. Redis 只是缓存，还是承载关键状态？
  2. 单机内存能不能装下未来一年数据？
  3. 读写 QPS 是否需要水平扩展？
  4. 是否大量使用 Lua、多 key、事务、pipeline？
  5. 团队是否有能力处理故障切换和扩容？
  6. 可接受的成本和可用性目标是什么？

踩坑提醒

第一个坑，是一上来就上 Cluster。Cluster 能扩容，但复杂度也高。小系统如果只是缓存几万条基础资料，用 Cluster 反而会增加开发和运维负担。

第二个坑，是把主从当高可用。主从复制不等于自动故障切换。没有哨兵或外部切换机制，主节点挂了仍然需要人工处理。

第三个坑，是忽略数据一致性。Redis 复制通常是异步的，主节点刚写入还没同步给从节点时发生故障，可能会丢一小段数据。关键业务不能把 Redis 当唯一事实来源。

第四个坑，是跨 slot 操作太多。Cluster 选型前要盘点代码里是否大量使用 MGET、MSET、Lua、事务和批量删除。否则上线后会发现很多命令不再好用。

第五个坑，是只看 QPS 不看热点 key。即使是 Cluster，如果大量请求集中在一个超级热点 key 上，也可能打爆单个节点。热点数据要考虑本地缓存、拆 key、限流或预计算。

总结

Redis 集群模式没有绝对最好，只有适合当前阶段。数据量小、风险低，用单机或主从；需要自动故障切换，用 Sentinel；容量和吞吐需要横向扩展，用 Redis Cluster；团队想减少运维，可以考虑云托管。

选型时最重要的是把 Redis 在系统里的角色想清楚。它是缓存、锁、队列、会话，还是关键状态存储？角色不同，容灾、持久化、扩容和一致性要求也完全不同。