上一篇【第51篇】Cluster复制与故障转移——集群高可用机制下一篇【第53篇】Redis发布订阅——消息队列的轻量替代方案你站在Redis的十字路口面前有两条路左边是 Sentinel—— 一个独立的高可用哨兵系统站在Master旁边站岗放哨右边是 Cluster—— 一个内建高可用的分布式集群数据分片、自动故障转移一把梭选哪个这可不是抛硬币能决定的事。今天我们就来一场神仙打架把Standalone、Sentinel、Cluster三种部署模式从头到脚比较一遍最后给你一棵企业级决策树让你再也不用纠结。三种部署模式的架构Standalone单机模式最简单一个Redis实例搞定一切。Standalone 架构 ┌─────────────┐ │ Client │ └──────┬──────┘ │ v ┌─────────────┐ │ Redis 单机 │ │ 全部数据 │ │ 6379端口 │ └─────────────┘ 优点: 简单真的简单 缺点: 挂了就完了没有备份没有扩展Sentinel哨兵模式在Standalone基础上加了主从复制 哨兵监控。Sentinel 架构 ┌──────────────────────────────────────┐ │ Sentinel 集群 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │Sentinel-1│ │Sentinel-2│ │Sentinel-3│ │ │ └─────────┘ └─────────┘ └─────────┘ │ └──────────────────────────────────────┘ 监控 | 监控 | 监控 v ┌─────────────────────────────────────┐ │ 主从复制组 │ │ │ │ Master (6379) ──────┐ │ │ │ │ │ │ │ 同步复制 │ │ │ v v │ │ Slave-1 (6380) Slave-2 (6381) │ └─────────────────────────────────────┘ | ┌──────┴──────┐ │ Clients │ │ (通过Sentinel│ │ 获取主库地址)│ └─────────────┘Cluster集群模式数据分片 内建复制 自动故障转移。Cluster 架构 ┌──────────────────────────────────────────────┐ │ Client │ └──────────┬─────────────┬────────────┬─────────┘ │ │ │ v v v ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Master-A │ │ Master-B │ │ Master-C │ │ 槽0-5460 │ │槽5461- │ │槽10923- │ │ │ │ 10922 │ │ 16383 │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ v v v ┌──────────┐ ┌──────────┐ ┌──────────┐ │Slave-A1 │ │Slave-B1 │ │Slave-C1 │ └──────────┘ └──────────┘ └──────────┘ 特点: 数据分片、内置高可用、水平扩展全方位对比表格先上一张大表一目了然对比维度StandaloneSentinelCluster数据分片不支持不支持支持16384个槽高可用无支持自动故障转移支持内建故障转移数据量上限单机内存单机内存集群总内存水平扩展不支持不支持支持动态加节点写入QPS上限单机QPS单机QPS集群总QPS客户端复杂度低中需Sentinel客户端库高需Cluster客户端库运维复杂度低中高多Key操作支持支持仅限同槽Key事务支持完整完整仅限同槽KeyPub/Sub支持支持有限频道只在所在分片广播适用数据量 10GB 30GB10GB ~ TB级适用QPS 5万 5万10万 ~ 百万故障恢复时间手动重启10-30秒5-15秒额外组件无Sentinel进程至少3个无最低节点数11主至少1从3个Sentinel63主3从成本最低配置1台机器3台机器6台机器Sentinel 的适用场景Sentinel 适合以下情况1. 数据量适中不需要分片Sentinel 典型场景 ┌─────────────────────────────────┐ │ 你的数据量: 10GB ~ 30GB │ │ 你的QPS: 1万 ~ 5万 │ │ 单机Redis扛得住 │ │ 但你不能接受单点故障 │ │ → Sentinel 完美解决 │ └─────────────────────────────────┘2. 团队运维能力有限Sentinel 的部署和运维相对简单# 最小化Sentinel部署3个Sentinel 1主2从# Step 1: 部署主从redis-server--port6379--daemonizeyes# Masterredis-server--port6380--daemonizeyes--replicaof127.0.0.16379# Slaveredis-server--port6381--daemonizeyes--replicaof127.0.0.16379# Slave# Step 2: 部署Sentinelredis-sentinel sentinel-1.conf--port26379--daemonizeyesredis-sentinel sentinel-2.conf--port26380--daemonizeyesredis-sentinel sentinel-3.conf--port26381--daemonizeyes# sentinel.conf 配置示例port26379sentinel monitor mymaster127.0.0.163792sentinel down-after-milliseconds mymaster10000sentinel failover-timeout mymaster60000sentinel parallel-syncs mymaster13. 需要读写分离Sentinel 模式天然支持读写分离// Java Lettuce 实现读写分离lettuceClientRedisClient.create(RedisURI.create(redis-sentinel://127.0.0.1:26379,127.0.0.1:26380/0));// 从库自动发现读请求分散到从库Cluster 的适用场景1. 数据量大需要水平扩展Cluster 典型场景 ┌─────────────────────────────────┐ │ 你的数据量: 50GB ~ 1TB │ │ 你的QPS: 10万 ~ 百万 │ │ 单机Redis扛不住 │ │ 需要数据分片 水平扩展 │ │ → Cluster 是唯一选择 │ └─────────────────────────────────┘2. 高并发写入# 3主3从Cluster: 写入QPS可达15-20万# 6主6从Cluster: 写入QPS可达30-50万# 12主12从Cluster: 写入QPS可达60-100万# Cluster线性扩展示意:# 主库数 × 单机写QPS ≈ 集群总写QPS# 3主 × 5万 15万# 6主 × 5万 30万# 12主 × 5万 60万3. 需要在线扩容Cluster支持动态添加节点不需要停机# 添加新主库redis-cli--clusteradd-node127.0.0.1:7006127.0.0.1:7000# 重新分片redis-cli--clusterreshard127.0.0.1:7000企业级选型决策树画一棵决策树跟着走就能得出答案Redis 部署模式选择决策树 数据量 50GB 或 QPS 5万 ├─ 是 ──→ 需要多Key事务或Lua跨Key操作 │ ├─ 是 ──→ 评估能否用{hashtag}保证同槽 │ │ ├─ 能 ──→ Cluster ✓ │ │ └─ 不能 ──→ 考虑拆分业务到多个Sentinel组 │ └─ 否 ──→ Cluster ✓ │ └─ 否 ──→ 需要高可用7×24不间断 ├─ 否 ──→ Standalone开发/测试环境✓ └─ 是 ──→ 预算允许6节点 ├─ 是 ──→ 预计数据量会快速增长 │ ├─ 是 ──→ 直接上 Cluster避免二次迁移✓ │ └─ 否 ──→ Sentinel ✓ └─ 否 ──→ Sentinel3节点部署✓迁移路径从Standalone到Cluster如果你的系统正在从Standalone逐步演进这里有一条清晰的迁移路径Stage 1: Standalone → Sentinel迁移阶段 1 Before: After: ┌────────┐ ┌────────┐ │Redis │ → │Master │─── Slave-1 │单机 │ └────────┘─── Slave-2 └────────┘ ↑ ┌────┴────┐ │Sentinel │ │ ×3 │ └─────────┘# 迁移步骤:# 1. 配置现有Redis的主从复制# 2. 部署Sentinel# 3. 客户端切换到Sentinel模式# 4. 验证故障转移功能Stage 2: Sentinel → Cluster迁移阶段 2 Before: After: ┌────────────┐ ┌────────────────────┐ │Sentinel组1 │ │Cluster │ │MasterSlave│ → │M1─S1 M2─S2 M3─S3 │ └────────────┘ └────────────────────┘ ┌────────────┐ │Sentinel组2 │ 合并 数据分片到多个主库 │MasterSlave│ → └────────────┘# 迁移步骤:# 1. 部署Cluster集群新环境# 2. 使用redis-migrate-tool或自研工具迁移数据# 3. 双写方案过渡期写Cluster 写Sentinel# 4. 验证Cluster数据完整性# 5. 客户端切换到Cluster模式# 6. 下线Sentinel踩坑提示从Sentinel迁移到Cluster最大的坑是多Key操作。如果你的代码中有大量MGET key1 key2 key3这种操作在Cluster中只有当所有Key落在同一槽位时才能正常工作。迁移前一定要审计你的代码云厂商Redis服务对比如果不想自己运维各大云厂商都提供了托管Redis服务特性阿里云 Redis腾讯云 RedisAWS ElastiCache标准版Standalone支持支持支持高可用版Sentinel类支持支持支持Multi-AZ集群版Cluster支持支持支持最大内存64TB2TB86.46TB读写分离支持只读副本支持支持数据迁移DTS工具DTS工具ElastiCache Migration备份恢复支持支持支持监控告警云监控云监控CloudWatch版本升级在线升级在线升级在线升级价格示例~¥300/月8GB集群~¥250/月8GB集群~$100/月cache.r6g.large生产建议对于中小企业强烈建议使用云厂商的托管服务。自建Redis Cluster的运维成本故障排查、备份恢复、版本升级、监控告警远比你想象的高。除非你有专门的DBA团队否则托管服务是更划算的选择。生产环境运维注意事项监控不管选哪种模式以下指标都需要监控核心监控指标:内存:-used_memory / maxmemory 利用率-used_memory_peak 峰值-eviction_count 淘汰计数性能:-instantaneous_ops_per_sec 当前QPS-latency_percentiles_usec 延迟分位数复制Sentinel/Cluster:-master_link_status 主从连接状态-master_repl_offset 复制偏移量-repl_backlog_size 复制缓冲区大小集群Cluster:-cluster_state 集群状态ok/fail-cluster_stats_messages_sent Gossip消息发送数持久化:-rdb_last_bgsave_status RDB最后保存状态-aof_last_write_status AOF最后写入状态备份策略模式备份方式恢复时间StandaloneRDB快照 / AOF分钟级Sentinel各节点独立备份分钟级Cluster各主库独立备份分钟级但恢复需要重建集群升级策略滚动升级流程适用于Sentinel和Cluster ① 先升级从库不影响服务 ② 确认从库升级后同步正常 ③ 对从库执行 CLUSTER REPLICATE / slaveof 切换Sentinel模式手动 ④ 触发故障转移让已升级的从库变为主库 ⑤ 升级原来的主库现在是从库了 ⑥ 重复以上步骤直到所有节点升级完成混合部署方案还需要 Cluster Sentinel 吗答案是通常不需要。在Redis Cluster出现之前有些架构是Cluster负责分片 Sentinel负责高可用。但Redis Cluster从3.0开始就内置了故障转移功能所以这种组合在现代架构中已经没有意义了。过时方案 vs 现代方案 过时方案不推荐: ┌─────────────────────────────┐ │ Cluster 节点组1 │ │ M1-S1 (Sentinel监控) │ ├─────────────────────────────┤ │ Cluster 节点组2 │ │ M2-S2 (Sentinel监控) │ └─────────────────────────────┘ → 复杂度高Sentinel和Cluster的故障转移可能冲突 现代方案推荐: ┌─────────────────────────────┐ │ Cluster │ │ M1-S1 M2-S2 M3-S3 │ │ 内置故障转移无需Sentinel │ └─────────────────────────────┘ → 简洁Cluster自带一切唯一可能需要Sentinel的场景是你有一套独立的、小规模的Redis实例不参与Cluster但需要高可用监控。这种情况下Sentinel仍然是最合适的选择。本章小结决策因素选 Standalone选 Sentinel选 Cluster开发/测试环境YES--数据量 10GBYESOK杀鸡用牛刀数据量 10-50GBNOYESOK数据量 50GBNONOYESQPS 1万YESOKNOQPS 1-5万NOYESOKQPS 5万NONOYES需要7×24高可用NOYESYES预算有限YESOKNO运维能力强任意OKYES最后送你一句话没有银弹只有最适合你当前阶段的选择。如果你还在早期Standalone就够了数据量上来了但还能单机扛住Sentinel给你高可用保障数据量大到单机扛不住了那就毫不犹豫上Cluster。上一篇【第51篇】Cluster复制与故障转移——集群高可用机制下一篇【第53篇】Redis发布订阅——消息队列的轻量替代方案