📚 课程目录第2章 Redis集群部署模式与监控对象梳理

2. Redis集群部署模式与监控对象梳理

要对Redis做大规模集群监控，第一步不是急着装Exporter或配告警，而是先把“部署模式”和“监控对象”这两件事对齐。因为主从、哨兵、Cluster三种模式的拓扑结构完全不同，同一个指标在不同模式下的含义、采集路径和告警阈值都可能不一样。如果监控对象定义错了，后面所有采集、看板、告警都会建立在错误的前提上。

三种部署模式的本质差异

主从模式是最基础的复制结构：一个主节点（Master）承担读写，一个或多个从节点（Replica）通过复制流同步数据。从节点默认只读，主要作用是数据冗余和读扩展。它的监控重点是复制关系是否健康——主从偏移量（offset）差距、复制是否断开、从节点延迟。主从模式没有自动故障转移，主节点挂了需要人工介入，所以监控要能第一时间发现主节点不可用。

哨兵模式在主从基础上增加了一组Sentinel进程，负责监控主从节点、判断主节点是否客观下线（ODOWN）、并在多数Sentinel同意后执行故障转移。这里监控对象多了一层：Sentinel自身也是被监控对象。需要关注Sentinel数量是否满足奇数、是否达到quorum、是否出现多个Sentinel对主节点状态判断不一致。哨兵模式下，客户端通过Sentinel获取当前主节点地址，所以“主节点是谁”是动态变化的，监控系统必须能跟随故障转移更新目标。

Cluster模式是分片集群，数据按16384个哈希槽（slot）分布到多个主节点上，每个主节点可以带若干从节点。Cluster没有中心节点，节点之间通过Gossip协议交换状态。它的监控对象最复杂：除了每个节点的内存、连接、命令统计，还要监控槽位分配是否完整、是否有槽处于迁移中、集群状态是ok还是fail、节点间是否失联。Cluster模式下，一次操作可能涉及多个节点，所以监控不能只看单节点，还要看整个集群的槽覆盖和节点握手状态。

监控对象的分层定义

把三种模式放在一起看，监控对象可以归纳为四层，每层采集的指标和判断逻辑不同。

节点层是最细的粒度，对应每一个Redis实例。无论哪种模式，每个节点都要采集角色（master/replica）、运行状态、内存使用、连接数、命令QPS、慢查询数量、持久化状态。在主从和哨兵模式下，节点层还要额外采集复制偏移量和复制延迟；在Cluster模式下，节点层要采集该节点负责的槽位范围。

分片与槽位层是Cluster模式特有的。Cluster把16384个槽分配给主节点，监控必须确认所有槽都有归属、没有槽处于迁移中、集群状态为ok。如果出现槽未分配或集群状态fail，说明集群已经不可用，这比单节点内存高要严重得多。这一层的监控对象不是某个进程，而是整个集群的拓扑状态。

代理层出现在使用Proxy（如Codis、Twemproxy或自研代理）接入Redis集群的场景。代理层监控的是代理进程本身是否存活、后端节点是否健康、转发QPS和延迟、连接池使用率、路由错误计数。代理层是客户端和Redis之间的中间层，它出问题会导致所有请求失败，所以代理层的存活和转发成功率是核心指标。

哨兵层只在哨兵模式下存在。Sentinel进程本身需要被监控：进程是否存活、监控的主节点地址是否正确、是否出现SDOWN或ODOWN、故障转移是否成功、quorum配置是否一致。哨兵层监控的一个关键点是“Sentinel数量”，如果只剩一个Sentinel，故障转移就无法完成，这属于高危状态。

监控对象与采集方式的对应关系

不同监控对象的采集方式不同。节点层和哨兵层通常通过Redis协议直接采集，比如执行INFO replication、INFO memory、SENTINEL masters等命令。Cluster的槽位和集群状态通过CLUSTER INFO、CLUSTER NODES、CLUSTER SLOTS获取。代理层则要看代理自身暴露的统计接口，比如HTTP管理端口或TCP统计命令。

下面是一个采集对象与命令的对应示例，实际部署时可以根据版本和工具调整：

# 节点层：复制状态与内存
redis-cli -h 10.0.1.11 -p 6379 INFO replication
redis-cli -h 10.0.1.11 -p 6379 INFO memory

# 哨兵层：主节点与下线状态
redis-cli -h 10.0.1.21 -p 26379 SENTINEL masters
redis-cli -h 10.0.1.21 -p 26379 SENTINEL sentinels mymaster

# Cluster层：槽位与集群状态
redis-cli -h 10.0.2.11 -p 6379 CLUSTER INFO
redis-cli -h 10.0.2.11 -p 6379 CLUSTER NODES
redis-cli -h 10.0.2.11 -p 6379 CLUSTER SLOTS

这些命令返回的字段就是监控指标的原始来源。比如INFO replication中的master_link_status为down表示复制断开，master_repl_offset与从节点的slave_repl_offset之差就是复制延迟的字节数。CLUSTER INFO中的cluster_state:ok和cluster_slots_assigned:16384是判断集群是否健康的直接依据。

在实际监控系统中，建议把“节点层”指标按实例维度打标签（cluster、role、shard、slot_range），把“分片与槽位层”指标按集群维度聚合。这样既能下钻到单节点排查，也能在集群层面快速判断整体可用性。

模式差异对监控策略的影响

三种模式对监控策略的影响可以归纳为三点。第一，告警对象不同：主从模式重点告警主节点不可用和复制断开；哨兵模式重点告警Sentinel数量不足和故障转移失败；Cluster模式重点告警槽位未覆盖和集群状态fail。第二，拓扑发现方式不同：主从和哨兵模式需要维护主节点地址列表，哨兵模式下主节点地址会变化；Cluster模式需要通过CLUSTER NODES动态发现节点和槽位关系。第三，故障影响范围不同：主从模式主节点故障影响全部写请求；哨兵模式故障转移期间有短暂不可用；Cluster模式单分片故障只影响该分片上的槽，其他分片仍可服务。