Redis Sentinel 源码分析 - Sentinel 网络连接和Tilt模式

作者:Wen Hui

转载:中间件小哥

在上一篇文章中我们介绍了Sentinel的初始化和主循环,这一篇我们介绍Sentinel的网络连接以及tilt模式。

 

Sentinel的网络连接

在前面的文章曾经提到每个Sentinel实例会维护与所监测的主从实例的两个连接,分别是命令连接(Command Connection)和发布订阅连接(Pub/Sub Connection)。但是需要注意的是,Sentinel和其他Sentinel之间只有一个命令连接。下面将分别介绍命令连接和发布订阅连接的作用。

 

命令连接

Sentinel维护命令连接是为了与其他主从实例以及Sentinel实例通过发送接收命令的方式进行通信,例如:

1. Sentinel会默认以每1s间隔发送PING 命令给其他实例以主观判断其他实例是否下线。

2. Sentinel会通过Sentinel和主实例之间的命令连接每隔10s发送INFO命令给主从实例以得到主实例和从实例的最新信息。

3. 在主实例下线的情况下,Sentinel会通过Sentinel和从实例的命令连接发送SLAVEOF NO ONE命令给选定的从实例从而使从实例提升为新的主节点。

4. Sentinel会默认每隔1s发送is-master-down-by-addr命令以询问其他Sentinel节点关于监控的主节点是否下线。

在sentinel.c中的sentinelReconnectInstance函数中,命令连接的初始化如下:

 

发布订阅连接

Sentinel维护和其他主从节点的发布订阅连接作用是为了获知其他监控相同主从实例的Sentinel实例的存在,并且从其他Sentinel实例中更新对所监控的主从实例以及发送的Sentinel实例的认知。例如在主备倒换完成后,其他Sentinel通过读取领头的Sentinel的频道消息来更新新的主节点的相关信息(地址,端口号等)。

Sentinel在默认每隔2秒钟会发送Hello消息包到其对应的主从实例的__sentinel__:hello频道中。Hello消息格式如下:

__sentinel_:hello <sentinel地址> <sentinel端口号> <sentinel运行id> <sentinel配置纪元> <主节点名字 > <主节点地址> <主节点端口号> <主节点配置纪元>

当Sentinel通过订阅连接收到其他Sentinel发送的的Hello包时,会更新对主从节点以及S发送Sentinel的认知,如果收到自己发送的Hello包,则简单的丢弃不做任何处理。这部分代码逻辑是在sentinel.c中的sentinelProcessHelloMessage函数中定义的,由于篇幅原因在这里不做详细介绍。

在sentinel.c中的sentinelReconnectInstance函数中,发布订阅连接初始化如下:

 

is-master-down-by-addr 命令

Sentinel会默认每隔1s通过命令连接发送is-master-down-by-addr命令以询问其他Sentinel节点关于监控的主节点是否下线。另外,在主实例下线的情况下,Sentinel之间也通过is-master-down-by-addr命令来获得投票并选举领头Sentinel。is-master-down-by-addr格式如下:

is-master-down-by-addr: <主实例地址> <主实例端口号> <当前配置纪元> <运行ID>

如果不是在选举领头Sentinel过程中, <runid>项总为*,相反地,如果在Sentinel向其他Sentinel发送投票请求情况下,<runid>项为自己的运行id。这部分代码如下:

is-master-down-by-addr的命令回复格式如下:

1) <主节点下线状态>

2) <领头Sentinel运行ID >

3) <领头Sentinel配置纪元>

Sentinel在收到其他Sentinel命令回复后,会记录其他Sentinel回复的主实例在线状态信息,以及在选举领头Sentinel过程中的投票情况,这部分的代码逻辑定义在sentinel.c中的sentinelReceiveIsMasterDownByReply函数:

 

Tilt模式

Sentinel的Tilt模式会在以下两种情况下开启:

1. Sentinel进程被阻塞超过SENTINEL_TILT_TRIGGER时间(默认为2s),可能因为进程或系统I/O(内存,网络,存储)请求过多。

2. 系统时钟调整到之前某个时间值。

Tilt模式是一种保护机制,处于该模式下Sentinel除了发送必要的PING及INFO命令外,不会主动做其他操作,例如主备倒换,标志主观、客观下线等。但可以通过INFO 命令及发布订阅连接的HELLO消息包来获取外界信息并对自身结构进行更新,直到SENTINEL_TILT_PERIOD时长(默认为30s)结束为止,我们可以认为Tilt模式是Sentinel的被动模式。

判断Tilt模式的代码逻辑定义如下:

参考资料:

https://github.com/antirez/redis

https://redis.io/topics/sentinel

Redis设计与实现第二版黄健宏著

<think>好的,用户现在问的是关于将Redis的状态监控标志从status改为flags来判断Redis状态。我需要先理解用户的具体需求背景。 用户之前的问题是关于Sentinel查询结果中没有status=ok字段的情况,现在转向使用flags来监控状态。可能他们在使用Sentinel时遇到了困惑,或者发现官方文档或实践中推荐使用flags而不是status字段。我需要确认Redis Sentinel的响应结构中是否存在status字段,或者是否有变化。 首先,回忆一下Redis Sentinel的响应格式。根据经验,当使用`sentinel masters`或`sentinel master`命令时,返回的信息中包含flags字段,而status可能并不是一个标准的字段。例如,flags可能包含像“master”、“s_down”、“o_down”这样的状态。用户可能在之前的回复中看到我提到status=ok,但实际可能不存在,或者只是示例中的占位符。这时候用户可能遇到了实际问题,发现status字段不存在,需要改用flags来判断。 接下来,我需要解释为什么应该使用flags而不是status。可能是因为status字段可能已经被弃用,或者flags提供了更详细的状态信息。需要确认Redis官方文档中的相关信息,确保回答的准确性。例如,Redis Sentinel的文档中指出,flags字段用于表示主节点或Sentinel的各种状态,如主观下线(s_down)、客观下线(o_down)等。 然后,用户可能想知道如何正确解析flags字段。需要详细说明flags的可能取值及其含义,比如“master”表示正常主节点,“s_down”表示主观下线,“o_down”表示客观下线等。同时,要给出具体的命令示例,比如如何通过redis-cli查询flags,并解析这些值。 还需要考虑用户可能的使用场景,比如在脚本中自动化监控,如何提取处理flags字段。可能需要演示如何用命令行工具如grep或awk来提取这些信息,或者使用JSON解析工具处理输出。如果用户使用的是编程语言如Python或Go,可能需要示例代码来展示如何通过客户端库获取并解析flags。 另外,用户可能遇到的一些常见问题,比如flags中有多个状态标志时如何处理,或者如何区分不同的状态。需要说明flags字段可能包含多个以逗号分隔的状态,并提供相应的处理方法,例如检查是否包含特定关键词。 还要注意用户可能的误区,比如误判flags中的某些状态,或者不了解各个状态的含义。需要逐一解释每个可能的状态标志,帮助用户正确理解。 最后,总结使用flags的优势,比如更精确的状态判断、实时性更高、兼容性更好等,并强调在监控脚本或工具中使用flags字段的重要性,确保用户能够顺利过渡到使用flags进行状态监控。</think>```markdown ### 状态监控标志变更说明 #### 背景差异 1. **历史字段设计** - `status`字段曾是部分客户端库的封装字段(非原生字段) - `flags`是Redis Sentinel协议原生字段(直接反映底层状态) 2. **信息精度对比** ``` status=ok → 单一状态指示 flags=master,disconnected → 复合状态指示 ``` #### 核心字段解析 通过`redis-cli`查询flags: ```bash redis-cli -p 26379 sentinel master mymaster | grep flags ``` ##### 关键标志组合 | 标志组合 | 状态含义 | |-----------------------------|---------------------------------| | `master` | 正常主节点状态 | | `master,s_down` | 主观下线(当前Sentinel认为不可用) | | `master,o_down` | 客观下线(多个Sentinel达成共识) | | `master,s_down,slave` | 错误的主从角色混合状态 | #### 状态判断方法 ```bash # 获取完整状态信息 response=$(redis-cli -p 26379 sentinel master mymaster) # 提取flags字段 flags=$(echo "$response" | awk -F' ' '/flags/ {print $2}') # 状态判断逻辑 if [[ $flags == *"s_down"* ]]; then echo "警告:节点主观下线" elif [[ $flags == *"o_down"* ]]; then echo "紧急:节点客观下线" elif [[ $flags == *"master"* && ! $flags == *","* ]]; then echo "状态正常" fi ``` #### 监控指标优化建议 1. **多维度监控** ```bash # 同时监控关联指标 redis-cli -p 26379 sentinel master mymaster | grep -E 'flags|num-slaves|last-ok-ping-reply' ``` 2. **Prometheus监控示例** ```yaml - name: redis_sentinel_flags type: gauge help: "Redis master flags status" labels: flags: $flags expr: | count by (flags) ( redis_sentinel_master_info{master_name="mymaster"} ) ``` #### 版本兼容注意 | Redis版本 | 特性变化 | |----------|------------------------------| | < 3.2 | 无`link-pending-commands`字段 | | ≥ 5.0 | 新增` tilt`模式标志 | | ≥ 6.2 | 支持`no-script`标志 | #### 典型问题处理 **场景:** flags显示`master,s_down,slave` **处理步骤:** 1. 检查主节点`INFO replication`输出 2. 验证`sentinel monitor`配置的端口是否正确 3. 执行强制故障转移: ```bash redis-cli -p 26379 sentinel failover mymaster ``` 建议在监控系统中添加以下报警规则: ```bash # 持续10分钟无正常标志 ALERT RedisMasterStatus IF redis_sentinel_flags{flags!~".*master.*"} > 0 FOR 10m LABELS { severity: "critical" } ANNOTATIONS { summary: "Redis主节点状态异常", description: "主节点{{ $labels.instance }}异常状态持续超过10分钟" } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值