Redis主从切换压测需结合压测、故障注入与监控闭环验证：先搭建哨兵或Cluster环境并配置客户端自适应刷新，再用redis-benchmark施加持续读写压力，接着kill主节点触发故障，实时观测服务可用性、切换时效性及客户端恢复能力，最后验证数据一致性与业务连续性。

Redis 主从切换机制本身不是直接“压测”的对象，而是故障转移过程的可靠性与时效性需要验证。真正的压力测试目标是：在高并发读写场景下，模拟主节点宕机，观察集群能否快速完成主从切换、客户端是否能自动重连新主、业务是否中断、数据是否一致。整个过程需结合压测 + 故障注入 + 监控观察三步闭环。

---

一、压测前先搭建可验证的主从+哨兵或 Cluster 环境

确保架构支持自动故障转移：

• 哨兵模式：至少3个哨兵 + 1主2从（推荐），sentinel monitor mymaster 127.0.0.1 6379 2 中的 quorum ≥ ⌈哨兵数/2⌉+1。
• Cluster 模式：6节点（3主3从），每个主有1个从，槽位均匀分配。
• 客户端必须启用自适应拓扑刷新（如 Lettuce 的 adaptiveRefreshTriggersPolicy 和 refreshPeriod）。

✅ 关键检查点：redis-cli -p 26379 sentinel masters mymaster 查看当前主节点；redis-cli -c -p 7000 cluster nodes 确认 Cluster 状态为 ok。

---

二、用 redis-benchmark 持续施加读写压力

在切换前启动稳定流量，模拟真实负载：

# 持续压测 SET/GET（混合读写，-t 同时指定多个命令）
redis-benchmark -h 127.0.0.1 -p 6379 -c 200 -n 0 -t set,get,incr,lpush,rpop -d 128 -P 10

# 或针对 Cluster，使用 -c 参数连接任意节点（自动重定向）
redis-benchmark -h 127.0.0.1 -p 7000 -c 100 -n 0 -t get,set -d 64

• -n 0 表示持续运行（非一次性10万请求），便于观察切换过程中的实时响应；
• -P 10 启用 pipeline，提升吞吐，更贴近生产流量特征；
• 建议压测 QPS 达到预期峰值的 70%~80%，避免压满导致超时掩盖切换问题。

---

三、触发故障并监控关键指标

在压测进行中，主动 Kill 主节点进程（非 shutdown，模拟宕机）：

# 示例：杀掉当前主节点（先确认它的 PID）
ps aux | grep "redis-server.*:6379" | grep -v grep
kill -9 <pid>

同时实时观测以下几类指标：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 服务可用性

  • 客户端是否报错（如 MOVED, ASK, Connection refused, No reachable node）；
  • 应用日志中 Redis 操作耗时突增或超时次数；
  • 是否出现写失败（主不可用期间写请求被拒绝）。

• 切换时效性

  • 哨兵模式：从 +sdown 日志 → +odown → +failover → +switch-master 的时间（通常 < 30 秒）；
  • Cluster 模式：从 fail? 状态 → fail → 从节点执行 CLUSTER FAILOVER 或自动选举成功的时间（官方建议 ≤ 1 分钟）；
  • 新主节点 INFO replication 中 role:master 出现时间。

• 客户端恢复能力

  • Lettuce 客户端需开启配置：

    spring:
      redis:
        lettuce:
          cluster:
            refresh:
              adaptive: true     # 启用自适应刷新
              trigger:
                reconnect: true
                move: true
              period: 30000      # 每30秒主动拉取拓扑

---

四、验证数据一致性与业务连续性

切换完成后，重点检查：

• 数据完整性
  对比切换前后 key 数量、某几个热点 key 的值（如计数器 incr counter 是否丢失）； 使用 redis-cli --scan --pattern "user:*" | wc -l 统计 key 总数是否一致。

• 连接连续性
  不重启应用，观察压测命令是否自动恢复（无 MOVED 重定向错误，响应延迟回归正常水平）； 若使用 Jedis，需确认是否配置了 JedisPoolConfig + JedisSentinelPool 并支持自动 failover。

• 异常兜底行为
  检查是否有大量 TRYAGAIN 或 CLUSTERDOWN 错误——说明集群短暂不可用，需优化 cluster-node-timeout（默认 15000ms，可调至 5000~8000ms 加速检测）。

不复杂但容易忽略