企业官网建设流程全解析

上一篇【第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 │ └──────────┘ └──────────┘ └──────────┘ 特点: 数据分片、内置高可用、水平扩展

全方位对比表格

先上一张大表，一目了然：

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 mymaster1

3. 需要读写分离

Sentinel 模式天然支持读写分离：

// Java + Lettuce 实现读写分离lettuceClient=RedisClient.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 ✓ └─ 否 ──→ Sentinel（3节点部署）✓

迁移路径：从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 │ │Master+Slave│ → │M1─S1 M2─S2 M3─S3 │ └────────────┘ └────────────────────┘ ┌────────────┐ │Sentinel组2 │ 合并 数据分片到多个主库 │Master+Slave│ → └────────────┘

# 迁移步骤:# 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 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最后写入状态

备份策略

升级策略

滚动升级流程（适用于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。

上一篇【第51篇】Cluster复制与故障转移——集群高可用机制
下一篇【第53篇】Redis发布订阅——消息队列的轻量替代方案