当前位置：首页 > 问答 > 正文

用Redis怎么搞服务连通性检测，连接状态啥时候断了也能知道

盘雅霜
问答
2026-01-06 07:28:58
25

心跳机制

要让服务之间知道对方还“活着”，并且能立刻发现对方“死”了，最直接有效的方法就是让它们互相“报平安”，这个方法就像两个人每隔几秒钟就互相喊一声“我在！”，如果有一方突然不喊了，另一方等了一会儿还没听到，就知道对方可能出事了，在技术里，这叫做“心跳机制”，Redis本身不直接提供一个“连接状态监听”的服务，但我们可以利用Redis的一些特性,非常巧妙地实现这个目标。

具体实现方法

主要有两种简单实用的方法：利用Redis的过期键功能和利用Redis的发布订阅功能。

利用Key的过期时间（TTL）

这个方法非常简洁,是实践中很常用的一种。

注册心跳：让每一个需要被检测的服务（我们叫它“服务A”）定期（比如每10秒钟）向一个共用的Redis服务器执行一个命令，这个命令是：SET key value EX seconds NX,这里面的门道是：
- key：这个key应该是唯一的，通常包含服务本身的标识符，service_heartbeat:订单服务_服务器IP。
- value：可以是一个时间戳或者任何简单的状态信息，比如online。
- EX seconds：这是关键，它设置这个key的过期时间，比如EX 15,意思是15秒后这个key会被Redis自动删除。
- NX：这个参数意思是“只有当这个key不存在时才设置”，这在服务刚启动时有用，但对于持续的心跳，更常用的可能是直接覆盖，所以有时也会省略NX，只用SET key value EX 15。
工作原理：服务A每隔10秒就执行一次这个SET命令，只要服务A是健康的，网络是通的，这个key就会一直被刷新，它的过期时间永远会从最后一次刷新开始重新计算为15秒，只要服务A活着,这个key就会一直存在于Redis中。
检测下线：另一个负责监控的服务（我们叫它“健康检查服务”），或者所有其他需要知道服务A状态的服务，可以定期去检查这个key是否存在，检查命令很简单，就是EXISTS key，如果返回1，说明服务A在最近15秒内报过平安，是健康的，如果返回0，说明这个key已经因为过期而被Redis自动删除了，意味着服务A已经超过15秒没有“心跳”了,大概率是服务挂了或者网络断了。
优点：
- 非常简单：只需要用到最基本的SET和EXISTS命令,逻辑清晰。
- 可靠：依赖Redis自身的过期删除机制,非常稳定。
- 负担轻：每个服务只需要定期写一个很小的key，监控服务定期读一下,对Redis的压力很小。
缺点：
- 有延迟：发现故障的速度取决于心跳间隔和key的过期时间，比如设置过期时间为15秒，那么最坏情况下需要15秒才能发现服务下线，你不能把时间设得太短,否则网络稍微一波动就可能误判。
- 需要主动查询：监控服务必须不停地轮询检查key的存在,无法被动接收通知。

利用发布订阅（Pub/Sub）

这个方法更“主动”一些，能让服务在断开时立刻（或近乎立刻）被感知。

订阅频道：让所有服务在启动时，都订阅一个共同的频道，比如叫做 heartbeat_channel，它们也需要订阅一个与自己唯一标识相关的频道，service_订单服务，使用Redis的SUBSCRIBE命令。
发布心跳：每个服务仍然定期（比如每10秒）发布心跳消息，但这次不是写key，而是使用PUBLISH命令，它向那个共同的频道 heartbeat_channel 发布一条消息，内容可以是“服务A在线”。
工作原理：所有订阅了 heartbeat_channel 的服务都会收到这条消息，这样，服务B只要收到了服务A的心跳消息，就知道服务A还活着,这本身就是一个直接的心跳感知。
检测下线 - 连接断开事件：这是Pub/Sub方法的精髓，当一个服务（服务A）与Redis的连接意外断开时（比如进程崩溃、机器断电、网络中断），Redis服务器会立刻感知到这个TCP连接的关闭，随后，Redis会自动向这个连接之前订阅的所有频道，发送一条特殊的“连接断开”消息（这条消息的内容通常是类似 unsubscribe 或连接关闭的通知，具体取决于客户端和配置）。
接收下线通知：其他服务（比如服务B）因为订阅了共同的频道，它们会收到来自Redis的、关于服务A断开连接的消息，服务B解析这条消息，发现是服务A掉线了，就可以立即触发处理逻辑,比如标记服务A为下线状态。
优点：
- 近乎实时：发现故障的速度非常快，几乎是网络TCP连接断开的那一刻就能知道,延迟极低。
- 被动通知：不需要轮询，节省资源,反应迅速。
缺点：
- 可靠性依赖连接：如果服务A是正常关闭的，它会先取消订阅(UNSUBSCRIBE)，这样Redis就不会发送断开消息了，所以这种方法主要适用于意外中断，对于正常关闭,可能需要结合方法一的心跳超时来判断。
- 消息不可靠：Redis的Pub/Sub模式是“发后即忘”的，如果监控服务在消息发出时刚好不在线，就会错过这条消息,它不像专业的消息队列有消息持久化机制。
- 客户端实现稍复杂：需要处理好订阅、接收消息以及解析各种系统消息的逻辑。

总结与选择

方法一（Key过期） 更像是一个“打卡机”，简单粗暴，稳定可靠，能同时处理正常关闭和异常中断，但发现故障有延迟，适用于对实时性要求不是极高,但要求稳定简单的场景。
方法二（Pub/Sub） 更像一个“对讲机”，能实现近乎实时的故障发现，特别擅长捕捉意外的连接中断，但需要处理更多边界情况，且消息可能丢失,适用于对故障发现延迟非常敏感的场景。

在实际生产中，很多人会选择方法一，因为其简单性和可靠性足以满足大多数需求，有时候也会将两种方法结合使用，用Pub/Sub来做实时报警,用心跳Key来做最终的状态确认和容错。

引用来源说明的核心思路和实现方法，是基于Redis官方文档中关于键过期（Expiration） 和发布订阅（Pub/Sub） 两大功能的经典应用，在Redis官网的《Redis Persistence》章节中提到了键过期是内存数据集的一个核心特性；在《Pub/Sub》章节中详细说明了消息传递和客户端断开时的行为，这些基础功能被广泛讨论和应用在分布式系统设计的实践中，例如用于实现服务发现、健康检查和分布式锁等模式。