Redis高可用架构解析

Nontee22
15 阅读10分钟

解析Sentinel与Cluster高可用架构

1. 问题背景：缓存单点的切肤之痛

在负责某内容管理系统（CMS）的架构演进过程中，我们曾遭遇过一次典型的线上事故。系统初期为追求交付效率，缓存层直接采用单节点Redis部署。在一次常规的内核补丁维护后，Redis实例未能按预期自动拉起。由于应用层未配置合理的降级与重试策略，核心读取接口瞬间击穿数据库。连接池迅速耗尽，网关层堆积大量超时请求，最终返回大面积502错误。

虽然通过手动重启在十分钟内恢复了服务，但这次短暂的中断直接影响了数千名用户的正常访问。业务监控大盘的断崖式下跌，彻底暴露了单点故障在核心依赖组件中的致命隐患。缓存层作为读写流量的第一道缓冲带，其可用性直接决定了系统的整体韧性。

2. 问题分析：为什么缓存必须高可用？

单点故障（Single Point of Failure, SPOF）指系统中某个组件一旦失效，将导致整个服务链路中断的设计缺陷。在内容管理系统中，Redis承担着热点文章元数据、会话状态、限流计数等关键职责。其宕机不仅引发读延迟飙升，更会触发缓存击穿与雪崩效应，底层数据库在瞬时高压下极易发生锁竞争或OOM，形成级联故障。

现代互联网架构对缓存层的要求早已超越“提升QPS”的基础定位，而是将其视为系统稳定性的基石。为此，Redis官方提供了两套成熟的高可用方案：Sentinel（哨兵模式）与Cluster（集群模式）。两者在架构哲学、数据分布与运维边界上存在本质差异，理解其底层机制是进行技术选型的前提。

3. 技术方案详解

3.1 Redis Sentinel：智能的“备用机组”

Sentinel的核心定位是高可用与故障自动转移。可将其类比为航空公司的备用机组调度系统：当主驾驶（Master）因突发状况失去响应，备用机组（Sentinel集群）会通过交叉验证迅速评估状态，并在满足法定条件后，自动指派副驾驶（Slave）接管指挥权，确保航班（服务）不中断。

其工作机制依赖三个并行运行的定时任务：

  1. 监控任务：每10秒向Master与Slave发送INFO命令，同步拓扑结构与从节点状态。
  2. 健康检查：每1秒发送PING命令。若节点在down-after-milliseconds阈值内未有效回复，标记为主观下线（SDOWN）。
  3. 故障决策：当足够数量的Sentinel节点确认同一主节点SDOWN时，升级为客观下线（ODOWN），触发Leader选举与故障转移流程。

架构通常采用“一主多从 + 奇数个哨兵”部署。哨兵节点本身通过去中心化共识维持状态，避免监控系统自身成为新的单点。

sequenceDiagram
    participant S1 as Sentinel-1
    participant S2 as Sentinel-2
    participant S3 as Sentinel-3
    participant M as Master
    participant SL as Slave
    participant C as Client

    M-->>S1: PING 超时
    M-->>S2: PING 超时
    M-->>S3: PING 超时
    S1->>S2: 确认SDOWN
    S2->>S3: 确认ODOWN (Quorum达成)
    S1->>S1: 发起Raft选举
    S2->>S1: 投票
    S3->>S1: 投票
    S1->>SL: 执行 SLAVEOF NO ONE (晋升新主)
    S1->>SL: 更新ACL与配置
    S1->>C: 发布 +switch-master 频道消息
    C->>SL: 重连新主，恢复读写

3.2 Redis Cluster：弹性的“物流分仓系统”

Cluster的设计目标是高可用与水平扩展。将其类比为大型电商的物流分仓网络：海量商品（数据）不再集中存放于单一总仓，而是根据标准化编码（哈希槽）分散存储至多个区域仓库。每个仓库独立运营，互不干扰，且具备独立的备用仓（从节点）。

Cluster采用去中心化架构，摒弃了早期依赖代理的路由方案。集群将16384个Hash Slot均匀分配给多个Master节点。客户端发送请求时，通过公式 CRC16(key) % 16384 计算目标槽位。若请求误发至非归属节点，服务端将返回 MOVED 或 ASK 响应码，指引客户端重定向至正确节点。当某个Master宕机，其对应的Slave会自动晋升，分片数据持续可用。该设计使得Cluster能够轻松突破单机内存限制，实现存储容量与吞吐能力的线性增长。

4. 核心区别对比

维度Redis SentinelRedis Cluster
设计目标故障自动转移，保障单分片高可用数据分片存储，兼顾高可用与水平扩展
数据分布全量复制（每个节点持有完整数据集）哈希槽分片（节点仅持有部分数据子集）
扩展能力仅支持垂直扩展，受单机内存上限制约支持水平扩展，动态增删节点与槽位迁移
客户端适配需支持Sentinel协议，动态获取主节点地址需支持Cluster协议，处理重定向与槽位路由
运维复杂度低，拓扑清晰，故障转移对业务基本透明中高，需管理槽位分布、节点扩缩容与重平衡
适用场景数据量通常小于50GB，读多写少的中小规模业务数据量庞大、高并发、需弹性伸缩的大规模系统

5. 实战演示：Docker环境下的Sentinel部署

以下提供基于Docker Compose的快速搭建方案，覆盖主从复制与哨兵监控的核心配置。

version: '3.8'
services:
  redis-master:
    image: redis:7-alpine
    container_name: redis-master
    command: redis-server --requirepass "SecurePass123" --masterauth "SecurePass123" --appendonly yes
    ports: ["6379:6379"]
    volumes: ["./data/master:/data"]

  redis-slave1:
    image: redis:7-alpine
    container_name: redis-slave1
    command: redis-server --slaveof redis-master 6379 --masterauth "SecurePass123" --requirepass "SecurePass123" --appendonly yes
    depends_on: ["redis-master"]

  redis-slave2:
    image: redis:7-alpine
    container_name: redis-slave2
    command: redis-server --slaveof redis-master 6379 --masterauth "SecurePass123" --requirepass "SecurePass123" --appendonly yes
    depends_on: ["redis-master"]

  sentinel1:
    image: redis:7-alpine
    container_name: sentinel1
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    ports: ["26379:26379"]
    volumes: ["./sentinel1.conf:/usr/local/etc/redis/sentinel.conf"]
    depends_on: ["redis-master", "redis-slave1", "redis-slave2"]

  sentinel2:
    image: redis:7-alpine
    container_name: sentinel2
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    ports: ["26380:26379"]
    volumes: ["./sentinel2.conf:/usr/local/etc/redis/sentinel.conf"]
    depends_on: ["redis-master", "redis-slave1", "redis-slave2"]

  sentinel3:
    image: redis:7-alpine
    container_name: sentinel3
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    ports: ["26381:26379"]
    volumes: ["./sentinel3.conf:/usr/local/etc/redis/sentinel.conf"]
    depends_on: ["redis-master", "redis-slave1", "redis-slave2"]

核心配置项 sentinel.conf 解析：

# 监控主节点：名称 主机 端口 法定票数(Quorum)
sentinel monitor mymaster redis-master 6379 2
# 认证密码
sentinel auth-pass mymaster SecurePass123
# 连续无响应判定主观下线的阈值（毫秒）
sentinel down-after-milliseconds mymaster 5000
# 故障转移总超时时间，涵盖选举、同步、配置更新
sentinel failover-timeout mymaster 10000
# 故障转移后，允许同时向新主发起全量同步的从节点数
sentinel parallel-syncs mymaster 1
  • parallel-syncs 设为1可避免多个从节点同时拉取RDB导致新主网络带宽打满。
  • failover-timeout 需结合网络延迟与数据量评估，过短易导致误判，过长则延长业务不可用窗口。

Spring Boot集成配置示例：

spring:
  redis:
    password: SecurePass123
    sentinel:
      master: mymaster
      nodes: localhost:26379,localhost:26380,localhost:26381
    lettuce:
      pool:
        max-active: 20
        max-idle: 10
        min-idle: 5
        max-wait: 3000ms
      cluster:
        refresh:
          adaptive: true
          period: 30s

Spring Data Redis底层通过Lettuce客户端订阅哨兵的+switch-master频道。主节点切换时，连接池自动断开旧连接，获取新拓扑并重建连接，业务代码无需感知地址变更。

6. 效果验证：故障转移全流程观测

部署完成后，执行 docker stop redis-master 模拟宕机。通过日志可清晰观测转移轨迹：

  1. 主观下线：Sentinel连续5次PING无响应，标记Master为SDOWN。
  2. 客观下线：达到Quorum（2票）后，状态升级为ODOWN，触发Leader选举。
  3. 选举与切换：基于Raft简化算法，epoch最大的Sentinel成为Leader。Leader向票数最高的Slave发送 SLAVEOF NO ONE，完成角色晋升。
  4. 拓扑更新：新主节点更新自身配置，旧从节点指向新主同步。哨兵广播切换事件。

使用 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster 验证，地址已切换至原从节点。业务侧仅经历短暂重试（通常300~800ms），无数据丢失，CMS页面恢复正常加载。

7. 深入探讨：生产环境的暗礁与航标

7.1 Sentinel选举与脑裂防御

Sentinel依赖多数派共识，当网络分区导致部分节点与主节点失联，可能形成“脑裂”：旧主仍在接收部分客户端写入，新主已对外服务，造成数据不一致。生产环境务必配置：

min-replicas-to-write 1
min-replicas-max-lag 10

该配置要求主节点至少拥有1个延迟低于10秒的从节点，否则拒绝写入。配合合理的 down-after-milliseconds，可大幅降低脑裂概率。

7.2 Cluster的数据迁移与重分片

Cluster扩容依赖 redis-cli --cluster reshard。迁移期间，源节点通过 MIGRATE 命令逐批将Key发送至目标节点。为保证一致性，Redis采用 ASKING 与 MOVED 机制：若Key正在迁移中，旧节点返回 ASK 指引客户端至目标节点临时查询；迁移完成后返回 MOVED 更新客户端本地路由缓存。建议在业务低峰期执行重分片，并配合监控指标 migrate_cached_sockets 观察连接池状态。

7.3 生产部署建议

  • 节点规划：Cluster建议至少3主3从，跨可用区（AZ）部署主从节点，防范机房级故障。
  • 网络规划：关闭Transparent Huge Pages (THP)，配置 net.core.somaxconn=1024 与 vm.overcommit_memory=1。
  • 规模边界：Cluster节点数建议控制在16个以内。节点过多会导致Gossip协议同步延迟呈指数级上升，拓扑收敛变慢。
  • 监控体系：集成 redis_exporter + Prometheus，重点告警 master_link_status、rejected_connections、cluster_state 与慢查询日志。

7.4 选型决策树

数据规模是否超出单机内存安全线(约32GB)?
├─ 否 → 读写比例是否严重失衡(读>>写)?
│     ├─ 是 → 选用 Sentinel (架构轻量，运维成本低)
│     └─ 否 → 单机主从 + 应用层重试/降级
└─ 是 → 客户端语言对Cluster协议支持是否成熟?
      ├─ 是 → 选用 Cluster (弹性扩展，长期演进首选)
      └─ 否 → 评估代理层方案(如Envoy/自研Proxy)或升级SDK

8. 总结与展望

Redis高可用架构的本质，是以冗余换稳定，以空间换时间。Sentinel以轻量级监控与自动化故障转移见长，适合数据规模可控、追求快速落地的传统业务；Cluster则以去中心化分片打破单机瓶颈，契合云原生时代对弹性与海量吞吐的诉求。

高可用设计并非孤立的技术堆砌，需与持久化策略（RDB快照+AOF混合）、客户端重试退避、限流降级机制协同运作，方能构建真正具备韧性的缓存底座。随着云托管Redis服务的普及，底层运维复杂度逐渐下沉，但掌握哨兵共识机制、分片路由逻辑与脑裂防御策略，依然是架构师应对复杂线上问题、进行精准容量规划与成本优化的核心底气。未来，结合Redis Stack的模块化扩展与Serverless化部署，缓存层的可用性与弹性将迈上新台阶，但“故障不可避免，快速恢复才是关键”的设计哲学，始终是不变的主轴。

avatar
文章
阅读
粉丝