Redis集群日常巡检必须聚焦槽位映射、拓扑感知、复制延迟三类真实故障源：需验证16384槽全分配且无孤立槽，主从复制延迟lag>3秒或offset差值超10000即高风险，Lettuce客户端须显式开启拓扑刷新（spring.redis.lettuce.cluster.refresh.period设为5000～10000），并检查节点内存与磁盘资源健康。
Redis集群部署完成后，日常巡检不能只看“节点通不通”，得聚焦槽位映射、拓扑感知、复制延迟这三类真实故障源。静态连通性正常但业务报 CLUSTERDOWN 或连接超时，90% 是巡检漏掉了关键项。
检查集群槽位分配与覆盖状态
集群必须满足 16384 个槽全部被分配且无孤立槽，否则客户端会直接拒绝写入。
- 用
redis-cli -c -h {host} -p {port} cluster info看cluster_state:ok和cluster_slots_assigned:16384—— 两者缺一不可 - 用
redis-cli -c -h {host} -p {port} cluster nodes检查每行末尾是否都有master或slave角色标记，且没有fail?或handshake状态残留 - 重点核对
cluster_slots_pfail和cluster_slots_fail是否为 0；非零值说明有槽处于疑似下线或已下线状态，需立刻查对应节点日志
验证主从复制延迟与同步完整性
主从不同步不一定会立刻报错，但会导致故障切换后数据丢失或客户端读到脏数据。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在每个 master 节点执行
redis-cli -h {master_host} -p {master_port} info replication，关注connected_slaves数量和各slave{N}_lag值；> 3 秒即属高风险 - 对比 master 的
master_repl_offset和 slave 的slave_repl_offset，差值超过 10000 表明积压严重，可能因网络抖动或 slave I/O 负载高导致 - 检查 slave 是否处于
state:online，而非state:connecting或state:sync长时间不退出（>5 分钟需干预）
确认客户端连接使用的拓扑是否实时更新
Lettuce 默认不刷新集群拓扑，节点增删或主从切换后，旧连接仍往已下线节点发请求，直接触发 MOVED 或 ASK 重定向失败。
- Spring Boot 应用必须显式开启拓扑刷新：配置项为
spring.redis.lettuce.cluster.refresh.period（单位毫秒），建议设为 5000～10000 - 若用 Jedis，则无需额外配置，但需确认依赖中已排除
lettuce-core，否则 Spring Boot 2.3+ 仍会优先加载 Lettuce - 验证方式：手动 kill 一个 master，等待 30 秒后执行
redis-cli -c -h {any_node} -p {port} set testkey testval；成功即说明客户端能自动重路由
检查节点级资源与持久化健康度
集群稳定不等于单节点健康。磁盘满、内存溢出、AOF rewrite 卡住都会让节点静默掉线。
- 每个节点执行
redis-cli -h {host} -p {port} info memory，确认used_memory_rss/maxmemorymem_allocator 不是libc（应为jemalloc） - 执行
redis-cli -h {host} -p {port} info persistence，检查aof_rewrite_in_progress:0和rdb_bgsave_in_progress:0；若为 1 且持续超 5 分钟，需查磁盘 I/O 或 fork 失败日志 - 检查系统层：
df -h /var/lib/redis（持久化目录）、free -h（避免 swap 使用）、cat /proc/{redis_pid}/status | grep -i oom（确认未被 OOM Killer 标记）
最容易被忽略的是：集群节点间时钟偏差。即使只有 200ms 差异，也会导致 cluster-node-timeout 判定失准，引发误踢节点。务必在所有 Redis 节点上运行 ntpq -p 并确保 offset 绝对值
