Redis Cluster故障处理机制

1. 问题场景

核心问题：Cluster模式下某个key所在的slot宕机如何处理？

术语澄清：

❌ 不是slot宕机（slot只是逻辑概念）
✅ 是持有该slot的Master节点宕机

典型场景

复制代码

集群初始状态：
┌─────────────────────────────────────────────────┐
│ Master1 (slot 0-5460)     → Slave1             │
│ Master2 (slot 5461-10922) → Slave2  ← 宕机！   │
│ Master3 (slot 10923-16383)→ Slave3             │
└─────────────────────────────────────────────────┘

问题：slot 5461-10922 范围内的数据会受影响

2. 故障检测机制

2.1 主观下线（PFAIL - Probably Fail）

定义： 单个节点认为目标节点已下线

检测流程

复制代码

时间轴：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
T0        T1-T15              T15
│         │                   │
Master2   其他节点发送PING     超时判定
宕机      持续无响应          标记PFAIL

判断条件：

节点在 cluster-node-timeout 时间内（默认15秒）没有响应PING
仅代表单个节点的判断，不代表真的下线

示例

bash 复制代码

# Master1的日志
[2025-12-10 10:00:00] Sending PING to Master2 (192.168.1.11:6379)
[2025-12-10 10:00:15] Timeout! Marking Master2 as PFAIL

2.2 客观下线（FAIL - Confirmed Fail）

定义： 集群中超过半数的Master节点都认为目标节点已下线

判定条件

复制代码

必要条件：超过半数Master确认PFAIL

示例计算：
┌─────────────────────┬──────────┬────────────┐
│ Master节点总数      │ 需要确认 │ 最少票数   │
├─────────────────────┼──────────┼────────────┤
│ 3个                 │ >3/2     │ 2票        │
│ 5个                 │ >5/2     │ 3票        │
│ 7个                 │ >7/2     │ 4票        │
└─────────────────────┴──────────┴────────────┘

Gossip协议传播

复制代码

Master1 发现Master2 PFAIL
    ↓
通过Gossip协议询问其他节点
    ↓
Master3 也确认Master2 PFAIL
    ↓
达成共识：Master2 = FAIL（客观下线）
    ↓
向所有节点广播 FAIL 消息

3. 故障转移流程

完整时间线

复制代码

T0秒   : Master2 宕机
         ║
T0-15秒: 其他节点持续PING，逐渐发现异常
         ║
T15秒  : 节点被标记为主观下线(PFAIL)
         ║
T15-16秒: Gossip协议传播，达成客观下线(FAIL)共识
         ║
T16秒  : Slave2 检测到Master下线
         ║
T16-17秒: Slave2 发起选举，收集投票
         ║
T17秒  : 选举成功，Slave2 提升为 Master2'
         ║
T17-18秒: 广播新的集群配置
         ║
T18秒  : 服务完全恢复
         ║
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
总耗时：约17-18秒

3.1 阶段一：从节点选举

选举条件

复制代码

Slave2 发起选举需要满足：
✓ 检测到自己的Master2已FAIL
✓ 数据复制偏移量足够新（数据不能太旧）
✓ 与Master断开时间不超过限制

投票过程

复制代码

Slave2 → Master1: 请求投票
         Master1: 同意！(1票)
       
Slave2 → Master3: 请求投票
         Master3: 同意！(1票)

需要票数：⌈Master总数/2⌉ + 1 = ⌈3/2⌉ + 1 = 2票
结果：Slave2 获得2票 → 选举成功！

多个从节点时的选举策略

复制代码

优先级判断：
1. 复制偏移量最大（数据最新）
2. 如果偏移量相同，选择run_id最小的

示例：
Master2 有两个从节点
┌──────────┬───────────────┬──────────┐
│ 节点     │ 复制偏移量    │ 选举结果 │
├──────────┼───────────────┼──────────┤
│ Slave2-1 │ 1000000      │ ✅ 当选  │
│ Slave2-2 │ 999800       │ ❌ 落选  │
└──────────┴───────────────┴──────────┘

3.2 阶段二：节点提升

提升步骤

复制代码

步骤1: Slave2 执行内部 CLUSTER FAILOVER 命令
       ↓
步骤2: Slave2 将自己标记为 Master
       ↓
步骤3: Slave2 接管 slot 5461-10922
       ↓
步骤4: 通过gossip协议广播配置更新
       ↓
步骤5: 所有节点更新集群拓扑信息

集群配置变化

复制代码

故障前：
Master1 (slot 0-5460)     → Slave1
Master2 (slot 5461-10922) → Slave2  ← 宕机
Master3 (slot 10923-16383)→ Slave3

故障后：
Master1  (slot 0-5460)     → Slave1
Master2' (slot 5461-10922) [原Slave2提升] ← 无从节点
Master3  (slot 10923-16383)→ Slave3

⚠️ 注意：原Master2宕机后，新的Master2'暂时没有从节点
建议：立即为Master2'添加新的从节点

3.3 阶段三：服务恢复

客户端重定向机制

复制代码

场景：客户端缓存了旧的slot映射

客户端 → 已下线的Master2: GET user:5500
         ↓
         (error) CLUSTERDOWN The cluster is down
         或
         (error) MOVED 5500 192.168.1.12:6379
         ↓
客户端更新slot映射缓存
         ↓
客户端 → 新的Master2': GET user:5500
         ↓
         成功返回数据 ✓

4. 不同场景的处理策略

场景A：Master有从节点（标准配置）✅

复制代码

配置：Master2 → Slave2

故障流程：
Master2宕机 → 检测(15s) → 选举(1-2s) → Slave2提升 → 服务恢复

结果：
✅ 自动故障转移
✅ 服务在17-18秒后恢复
⚠️ 期间该slot范围的请求会失败
⚠️ 最后几秒未同步的写入可能丢失

场景B：Master无从节点 ❌

复制代码

配置：Master2 (无Slave)

故障流程：
Master2宕机 → 检测(15s) → 无从节点可提升 → slot永久不可用

结果：
❌ slot 5461-10922 永久不可用
❌ 该范围的所有key无法访问
❌ 集群部分功能失效

恢复方式：
方案1: 修复故障节点并重启
方案2: 手动迁移slot到其他Master
方案3: 如果cluster-require-full-coverage=no，其他slot仍可用

手动迁移slot示例

bash 复制代码

# 将slot 5461-10922 迁移到Master1
redis-cli --cluster reshard 127.0.0.1:7000
# 按提示操作：
# - 迁移的slot数量：5462个
# - 目标节点ID：Master1的node_id
# - 源节点：Master2

场景C：同时多个Master宕机 ❌❌

复制代码

假设：3主3从，2个Master同时宕机

问题：
- 剩余1个Master，无法获得2票（需要2票）
- 无法完成选举
- 集群进入FAIL状态

结果：
❌ 整个集群不可用
❌ 所有请求失败

恢复：
需要手动恢复至少1个宕机的Master节点
使集群中运行的Master数量 > 总Master数/2

故障容忍度计算

复制代码

┌──────────────┬────────────┬──────────────┐
│ 集群配置     │ 容忍故障   │ 说明         │
├──────────────┼────────────┼──────────────┤
│ 3主3从       │ 1个Master  │ 最小配置     │
│ 5主5从       │ 2个Master  │ 推荐配置     │
│ 7主7从       │ 3个Master  │ 高可用配置   │
└──────────────┴────────────┴──────────────┘

场景D：网络分区（脑裂）⚠️

复制代码

网络分区导致集群被分成两部分：

分区A: Master1, Master2, Slave1, Slave2
分区B: Master3, Slave3

问题：
- 分区B中Master3少数派，无法完成选举
- 分区A中Master1和Master2多数派，可以继续服务
- 网络恢复后可能出现数据不一致

解决：
Redis Cluster会检测网络分区
少数派分区会停止接受写入

5. 客户端视角

5.1 请求处理的三种情况

情况1：故障转移期间

bash 复制代码

# 客户端发送请求到已宕机的Master2
$ redis-cli -c -p 7001
127.0.0.1:7001> GET order:8000

# 可能的响应：
(error) CLUSTERDOWN The cluster is down

# 或者TCP连接超时
Error: Connection timeout

情况2：故障转移完成后（旧映射）

bash 复制代码

# 客户端仍使用旧的slot映射
127.0.0.1:7001> GET order:8000

# 返回重定向
(error) MOVED 8000 192.168.1.12:6379

# 智能客户端自动：
# 1. 更新slot映射缓存
# 2. 连接到新的Master2'
# 3. 重新发送请求
-> Redirected to slot [8000] located at 192.168.1.12:6379
"order_data_value"

情况3：使用智能客户端

python 复制代码

# Python示例：redis-py-cluster
from redis.cluster import RedisCluster

# 初始化集群客户端
client = RedisCluster(
    startup_nodes=[
        {"host": "127.0.0.1", "port": 7000},
        {"host": "127.0.0.1", "port": 7001},
        {"host": "127.0.0.1", "port": 7002}
    ],
    decode_responses=True,
    skip_full_coverage_check=False,  # 确保集群完整性
    max_connections_per_node=50
)

# 自动处理故障转移和重定向
try:
    value = client.get("order:8000")
    print(f"Value: {value}")
except Exception as e:
    print(f"Error: {e}")
    # 客户端内部已自动：
    # 1. 检测MOVED/ASK错误
    # 2. 更新slot映射
    # 3. 重试请求

5.2 客户端最佳实践

✅ 推荐做法

python 复制代码

# 1. 使用连接池
client = RedisCluster(
    startup_nodes=nodes,
    max_connections_per_node=50  # 连接池大小
)

# 2. 实现重试机制
from tenacity import retry, stop_after_attempt, wait_fixed

@retry(stop=stop_after_attempt(3), wait=wait_fixed(1))
def get_with_retry(key):
    return client.get(key)

# 3. 捕获异常
try:
    value = get_with_retry("order:8000")
except ClusterDownError:
    logger.error("Cluster is down")
    # 降级处理
except Exception as e:
    logger.error(f"Unexpected error: {e}")

❌ 避免做法

python 复制代码

# ❌ 不要直连单个节点
client = redis.Redis(host='127.0.0.1', port=7000)

# ❌ 不要禁用重定向
client = RedisCluster(nodes, follow_cluster=False)

# ❌ 不要缓存slot映射太久
# 应该允许客户端自动更新映射

6. 关键配置参数

6.1 核心参数说明

参数名称	默认值	说明	影响
`cluster-node-timeout`	15000 (ms)	节点超时判定时间	故障检测速度
`cluster-slave-validity-factor`	10	从节点数据有效因子	选举资格判定
`cluster-replica-no-failover`	no	是否禁止自动故障转移	是否自动切换
`cluster-require-full-coverage`	yes	是否要求所有slot可用	部分宕机时集群可用性
`cluster-replica-validity-factor`	10	复制有效性因子	数据新鲜度要求

6.2 参数详解

cluster-node-timeout

ini 复制代码

# redis.conf
cluster-node-timeout 15000

作用：
- 节点被判定为PFAIL的超时时间
- 也影响从节点数据有效性判断

调整建议：
- 降低值：加快故障检测（可能增加误判）
- 提高值：减少误判（延长故障检测时间）

推荐值：
- 稳定网络：10000-15000 ms
- 不稳定网络：20000-30000 ms

cluster-slave-validity-factor

ini 复制代码

cluster-slave-validity-factor 10

作用：
判断从节点数据是否足够新，能否参与选举

计算公式：
最大允许断线时间 = cluster-node-timeout × cluster-slave-validity-factor

示例：
timeout = 15000ms
factor = 10
最大断线 = 15000 × 10 = 150000ms = 150秒

如果从节点与主节点断开超过150秒，不能参与选举

特殊值：
0 = 从节点永远有效，无论断开多久

cluster-require-full-coverage

ini 复制代码

# 默认配置
cluster-require-full-coverage yes

行为：
yes → 任何slot不可用，整个集群停止服务
no  → 只有不可用的slot无法访问，其他slot正常

示例场景：
Master2宕机且无从节点

cluster-require-full-coverage = yes:
- slot 5461-10922 不可用
- 整个集群返回 CLUSTERDOWN
- 所有slot都无法访问

cluster-require-full-coverage = no:
- slot 5461-10922 不可用
- slot 0-5460 和 10923-16383 正常访问
- 部分业务可以继续

推荐：
生产环境建议设置为 no，提高可用性

6.3 优化配置示例

ini 复制代码

# redis.conf - 生产环境推荐配置

# 故障检测优化
cluster-node-timeout 10000  # 10秒检测，比默认快

# 允许部分slot不可用
cluster-require-full-coverage no  # 提高可用性

# 从节点数据新鲜度
cluster-slave-validity-factor 10  # 标准配置

# 不禁止自动故障转移
cluster-replica-no-failover no  # 开启自动切换

# 其他相关配置
cluster-migration-barrier 1  # 至少保留1个从节点不迁移
cluster-allow-reads-when-down no  # 集群down时不提供读

7. 手动故障转移

7.1 CLUSTER FAILOVER 命令

基本用法

bash 复制代码

# 在从节点执行，主动提升为Master
redis-cli -h 192.168.1.12 -p 6379

# 标准故障转移（等待数据同步）
> CLUSTER FAILOVER
OK

# 此时：
# 1. 从节点与主节点同步数据
# 2. 主节点停止写入
# 3. 从节点提升为主节点
# 4. 原主节点降级为从节点

三种模式

bash 复制代码

# 1. 标准模式（推荐）
CLUSTER FAILOVER
- 等待与主节点数据完全同步
- 数据零丢失
- 耗时较长

# 2. FORCE模式
CLUSTER FAILOVER FORCE
- 不等待数据同步
- 强制提升
- 可能丢失少量数据

# 3. TAKEOVER模式（危险）
CLUSTER FAILOVER TAKEOVER
- 即使主节点可达也强制接管
- 不需要集群投票
- 可能造成脑裂
- 仅用于紧急情况

7.2 应用场景

场景1：升级维护

bash 复制代码

# 目标：无停机升级Master2

步骤1: 在Slave2执行标准故障转移
redis-cli -h slave2 -p 6379
> CLUSTER FAILOVER
OK

步骤2: 此时Master2降级为从节点，停止服务

步骤3: 升级原Master2
$ systemctl stop redis
$ yum update redis
$ systemctl start redis

步骤4: 原Master2作为从节点重新加入集群

场景2：机房迁移

bash 复制代码

# 目标：将Master从机房A迁移到机房B

当前：
- Master2 在机房A
- Slave2 在机房B

步骤1: 在机房B的Slave2执行故障转移
> CLUSTER FAILOVER

步骤2: Slave2（机房B）提升为Master
步骤3: 原Master2（机房A）降级为Slave
步骤4: 后续可以关闭机房A的节点

场景3：负载均衡

bash 复制代码

# 目标：平衡各节点的访问压力

当前：Master1负载高，Master2负载低

步骤1: 将高负载Master的部分slot迁移
redis-cli --cluster reshard 127.0.0.1:7000

步骤2: 或者通过故障转移调整主从位置

8. 监控与运维

8.1 集群健康检查

检查集群状态

bash 复制代码

# 1. 集群整体状态
redis-cli --cluster check 127.0.0.1:7000

# 输出示例：
127.0.0.1:7000 (node-id-1...) -> 1000 keys | 5461 slots | 1 slaves.
127.0.0.1:7001 (node-id-2...) -> 1000 keys | 5462 slots | 1 slaves.
127.0.0.1:7002 (node-id-3...) -> 1000 keys | 5461 slots | 1 slaves.
[OK] All 3000 keys verified.
[OK] All 16384 slots covered.

检查节点信息

bash 复制代码

# 2. 查看节点列表
redis-cli -p 7000 CLUSTER NODES

# 输出示例：
node-id-1 127.0.0.1:7000@17000 master - 0 1702200000 1 connected 0-5460
node-id-2 127.0.0.1:7001@17001 master - 0 1702200000 2 connected 5461-10922
node-id-3 127.0.0.1:7002@17002 master - 0 1702200000 3 connected 10923-16383
node-id-4 127.0.0.1:7003@17003 slave node-id-1 0 1702200000 1 connected
node-id-5 127.0.0.1:7004@17004 slave node-id-2 0 1702200000 2 connected
node-id-6 127.0.0.1:7005@17005 slave node-id-3 0 1702200000 3 connected

检查Slot分配

bash 复制代码

# 3. 查看slot分配情况
redis-cli -p 7000 CLUSTER SLOTS

# 输出示例：
1) 1) (integer) 0       # slot起始
   2) (integer) 5460    # slot结束
   3) 1) "127.0.0.1"    # master地址
      2) (integer) 7000
   4) 1) "127.0.0.1"    # slave地址
      2) (integer) 7003

8.2 故障相关监控

监控指标

bash 复制代码

# 查看集群信息
redis-cli -p 7000 CLUSTER INFO

# 关键指标：
cluster_state:ok                    # 集群状态
cluster_slots_assigned:16384        # 已分配slot数
cluster_slots_ok:16384              # 正常slot数
cluster_slots_pfail:0               # PFAIL状态slot数
cluster_slots_fail:0                # FAIL状态slot数
cluster_known_nodes:6               # 已知节点数
cluster_size:3                      # 集群主节点数
cluster_current_epoch:6             # 当前纪元
cluster_my_epoch:2                  # 当前节点纪元
cluster_stats_messages_sent:1000   # 发送消息数
cluster_stats_messages_received:800 # 接收消息数

监控脚本示例

bash 复制代码

#!/bin/bash
# monitor_cluster.sh - Redis集群监控脚本

REDIS_CLI="redis-cli -p 7000"

# 检查集群状态
check_cluster_state() {
    state=$($REDIS_CLI CLUSTER INFO | grep cluster_state | cut -d: -f2)
    if [ "$state" != "ok" ]; then
        echo "⚠️  Cluster state: $state"
        alert "Redis Cluster is down!"
    else
        echo "✅ Cluster state: ok"
    fi
}

# 检查slot覆盖
check_slot_coverage() {
    assigned=$($REDIS_CLI CLUSTER INFO | grep cluster_slots_assigned | cut -d: -f2)
    ok=$($REDIS_CLI CLUSTER INFO | grep cluster_slots_ok | cut -d: -f2)
    fail=$($REDIS_CLI CLUSTER INFO | grep cluster_slots_fail | cut -d: -f2)
  
    if [ "$fail" -gt 0 ]; then
        echo "⚠️  Failed slots: $fail"
        alert "Redis Cluster has $fail failed slots!"
    fi
}

# 检查节点状态
check_node_status() {
    $REDIS_CLI CLUSTER NODES | while read line; do
        if echo "$line" | grep -q "fail"; then
            node_id=$(echo "$line" | awk '{print $1}')
            echo "⚠️  Node $node_id is failed!"
            alert "Redis node $node_id is down!"
        fi
    done
}

# 主函数
main() {
    echo "=== Redis Cluster Monitor ==="
    check_cluster_state
    check_slot_coverage
    check_node_status
    echo "=== Monitor Complete ==="
}

main

8.3 日志分析

关键日志模式

bash 复制代码

# 1. 节点下线日志
grep "PFAIL" /var/log/redis/redis-7000.log
# 输出：
# [2025-12-10 10:00:15] Node 192.168.1.11:6379 marked as PFAIL

grep "FAIL" /var/log/redis/redis-7000.log
# 输出：
# [2025-12-10 10:00:16] Node 192.168.1.11:6379 marked as FAIL

# 2. 故障转移日志
grep "Failover" /var/log/redis/redis-7000.log
# 输出：
# [2025-12-10 10:00:17] Failover election started
# [2025-12-10 10:00:18] Failover election won
# [2025-12-10 10:00:18] Promoted to master

# 3. Slot迁移日志
grep "slot" /var/log/redis/redis-7000.log | grep -i "migrat"

8.4 告警建议

告警规则

yaml 复制代码

# Prometheus告警规则示例

groups:
  - name: redis_cluster_alerts
    rules:
      # 集群down告警
      - alert: RedisClusterDown
        expr: redis_cluster_state != 1
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Redis Cluster is down"
        
      # 节点下线告警
      - alert: RedisNodeDown
        expr: redis_cluster_known_nodes < 6
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: "Redis node is down"
        
      # Slot失败告警
      - alert: RedisSlotsFailed
        expr: redis_cluster_slots_fail > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Redis has failed slots"
        
      # 复制延迟告警
      - alert: RedisReplicationLag
        expr: redis_slave_repl_offset - redis_master_repl_offset > 1000000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Redis replication lag is high"

9. 最佳实践

9.1 架构设计

✅ 推荐配置

复制代码

1. 最小配置：3主3从（6节点）
   - 可容忍1个Master故障
   - 每个Master至少1个Slave

2. 推荐配置：5主10从（15节点）
   - 可容忍2个Master故障
   - 每个Master配2个Slave
   - 更高的读写分离能力

3. 高可用配置：每个Master至少2个Slave
   - 防止Master和唯一Slave同时故障
   - 提供更好的读性能

部署拓扑

复制代码

方案A：单机房部署（不推荐生产环境）
┌─────────────────────────────────┐
│          机房A                  │
│  Master1  Master2  Master3      │
│  Slave1   Slave2   Slave3       │
└─────────────────────────────────┘
风险：机房故障导致全部不可用

方案B：双机房部署
┌──────────────────┐  ┌──────────────────┐
│     机房A        │  │     机房B        │
│  Master1  Master2│  │  Master3         │
│  Slave3          │  │  Slave1  Slave2  │
└──────────────────┘  └──────────────────┘
优点：单机房故障仍可用

方案C：三机房部署（最佳）
┌─────────┐  ┌─────────┐  ┌─────────┐
│ 机房A   │  │ 机房B   │  │ 机房C   │
│ Master1 │  │ Master2 │  │ Master3 │
│ Slave2  │  │ Slave3  │  │ Slave1  │
└─────────┘  └─────────┘  └─────────┘
优点：最高可用性，任意机房故障不影响服务

9.2 运维规范

节点管理

bash 复制代码

# ✅ 添加新节点的正确流程

步骤1: 启动新节点
redis-server redis-7006.conf

步骤2: 加入集群
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000

步骤3: 分配slot（如果是Master）
redis-cli --cluster reshard 127.0.0.1:7000
# 按提示将部分slot迁移到新节点

步骤4: 或者配置为Slave
redis-cli -p 7006 CLUSTER REPLICATE <master-node-id>

步骤5: 验证
redis-cli --cluster check 127.0.0.1:7000

节点下线

bash 复制代码

# ✅ 安全下线节点的流程

如果是Master：
步骤1: 迁移所有slot到其他Master
redis-cli --cluster reshard 127.0.0.1:7000
# 将该节点的所有slot迁移出去

步骤2: 删除节点
redis-cli --cluster del-node 127.0.0.1:7000 <node-id>

如果是Slave：
直接删除（Master会选举其他Slave）
redis-cli --cluster del-node 127.0.0.1:7000 <node-id>

9.3 数据备份

bash 复制代码

# 定期备份策略

# 1. RDB自动备份
# redis.conf
save 900 1      # 900秒内至少1次写入
save 300 10     # 300秒内至少10次写入
save 60 10000   # 60秒内至少10000次写入

# 2. AOF持久化
appendonly yes
appendfsync everysec  # 每秒同步

# 3. 备份脚本
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
for port in 7000 7001 7002 7003 7004 7005; do
    redis-cli -p $port BGSAVE
    sleep 5
    cp /var/lib/redis/$port/dump.rdb /backup/redis/dump_${port}_${DATE}.rdb
done

9.4 性能优化

配置优化

ini 复制代码

# redis.conf 性能优化

# 1. 内存配置
maxmemory 8gb
maxmemory-policy allkeys-lru

# 2. 持久化优化
# RDB优化
save 900 1
save 300 10
stop-writes-on-bgsave-error yes
rdbcompression yes

# AOF优化（可选）
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 3. 网络优化
tcp-backlog 511
timeout 300
tcp-keepalive 300

# 4. 线程配置（Redis 6.0+）
io-threads 4
io-threads-do-reads yes

# 5. 慢查询监控
slowlog-log-slower-than 10000  # 10ms
slowlog-max-len 128

9.5 故障演练

定期演练计划

复制代码

月度演练：
□ 单Master节点宕机恢复
□ 单Slave节点宕机恢复
□ 网络分区模拟
□ 手动故障转移

季度演练：
□ 多节点同时故障
□ 整个机房故障
□ 数据恢复演练
□ 全链路压测

年度演练：
□ 灾难恢复演练
□ 跨机房迁移
□ 版本升级
□ 架构优化

总结

核心要点

方面	要点
故障检测	PFAIL(15秒) → FAIL(共识) → 选举(1-2秒)
故障转移	自动选举 → 从节点提升 → 广播配置
恢复时间	约17-18秒完成自动故障转移
数据丢失	最后未同步的写入可能丢失
配置要求	每个Master至少1个Slave（推荐2个）

关键配置

ini 复制代码

# 最小化故障转移时间
cluster-node-timeout 10000

# 提高可用性
cluster-require-full-coverage no

# 标准从节点配置
cluster-slave-validity-factor 10
cluster-replica-no-failover no

架构建议

复制代码

✅ 每个Master至少2个Slave
✅ 跨机房/机架部署
✅ 使用智能客户端
✅ 实现监控告警
✅ 定期故障演练
✅ 配置自动备份

故障应对清单

复制代码

□ 监控集群状态（cluster_state, cluster_slots_fail）
□ 检查节点健康（CLUSTER NODES）
□ 配置告警通知（Prometheus/Grafana）
□ 准备故障转移预案
□ 定期备份数据
□ 文档化操作流程
□ 定期演练恢复流程

笔记创建时间：2025-12-10
最后更新：2025-12-10

参考资料

Redis官方文档：https://redis.io/topics/cluster-tutorial
Redis Cluster规范：https://redis.io/topics/cluster-spec
Redis命令参考：https://redis.io/commands

Redis Cluster故障处理机制

Redis Cluster故障处理机制

目录

1. 问题场景

核心问题：Cluster模式下某个key所在的slot宕机如何处理？

典型场景

2. 故障检测机制

2.1 主观下线（PFAIL - Probably Fail）

检测流程

示例

2.2 客观下线（FAIL - Confirmed Fail）

判定条件

Gossip协议传播

3. 故障转移流程

完整时间线

3.1 阶段一：从节点选举

选举条件

投票过程

多个从节点时的选举策略

3.2 阶段二：节点提升

提升步骤

集群配置变化

3.3 阶段三：服务恢复

客户端重定向机制

4. 不同场景的处理策略

场景A：Master有从节点（标准配置）✅

场景B：Master无从节点 ❌

手动迁移slot示例

场景C：同时多个Master宕机 ❌❌

故障容忍度计算

场景D：网络分区（脑裂）⚠️

5. 客户端视角

5.1 请求处理的三种情况

情况1：故障转移期间

情况2：故障转移完成后（旧映射）

情况3：使用智能客户端

5.2 客户端最佳实践

✅ 推荐做法

❌ 避免做法

6. 关键配置参数

6.1 核心参数说明

6.2 参数详解

cluster-node-timeout

cluster-slave-validity-factor

cluster-require-full-coverage

6.3 优化配置示例

7. 手动故障转移

7.1 CLUSTER FAILOVER 命令

基本用法

三种模式

7.2 应用场景

场景1：升级维护

场景2：机房迁移

场景3：负载均衡

8. 监控与运维

8.1 集群健康检查

检查集群状态

检查节点信息

检查Slot分配

8.2 故障相关监控

监控指标

监控脚本示例

8.3 日志分析

关键日志模式

8.4 告警建议

告警规则

9. 最佳实践

9.1 架构设计

✅ 推荐配置

部署拓扑

9.2 运维规范

节点管理

节点下线

9.3 数据备份

9.4 性能优化

配置优化

9.5 故障演练

定期演练计划

总结

核心要点