心跳机制方案

简介: 心跳机制方案

心跳机制

心跳机制时,发送心跳包后判断设备是否离线

等待响应

发送心跳包后,需要等待对方设备的响应。可以设置一个合理的超时时间,如果在这个时间内没有收到响应,则可能表明对方设备有问题。

超时处理

如果在设定的超时时间内没有收到响应,应该认为对方设备可能离线或出现故障。这时,可以采取进一步的措施,如重试发送心跳包、记录日志、发送告警、尝试重新建立连接等。

重试机制

在确定对方设备离线之前,可以实施一定的重试机制。例如,连续几次心跳包均未得到响应后才判断为离线。这有助于避免因网络短暂抖动而错误地判断设备离线。

心跳包的响应内容

心跳响应不仅是一个简单的确认,有时可以包含设备的状态信息。通过分析这些信息,可以更准确地判断设备的健康状况。

多点检测

如果应用场景允许,可以从多个节点发送心跳包,以增加检测的可靠性。如果所有节点都无法接收到响应,那么可以更确定地判断设备离线。

整合监控系统

在大型系统中,心跳检测通常与监控系统整合,以实现更全面的状态监控和告警机制。

Netty保活机制

TCP层面的保活机制

TCP 协议本身提供了一个保活机制,通过在长时间未收到数据时向对端发送探测报文,以检测连接的状态。在 Netty 中,可以通过设置 childOption(ChannelOption.SO_KEEPALIVE, true) 来启用 TCP 层面的保活机制。

TCP长连接下,客户端和服务器若长时间无数据交互情况下,若一方出现异常情况关闭连接,抑或是连接中间路由出于某种机制断开连接,而此时另一方不知道对方状态而一直维护连接,浪费系统资源的同时,也会引起下次数据交互时出错。为了解决此问题,引入了TCP KeepAlive机制(并非标准规范,但操作系统一旦实现,默认情况下须为关闭,可以被上层应用开启和关闭)。其基本原理是在此机制开启时,当长连接无数据交互一定时间间隔时,连接的一方会向对方发送保活探测包,如连接仍正常,对方将对此确认回应。

TCP KeepAlive参数

KeepAlive为操作系统层面的参数.

tcp_keepalive_time (integer; default: 7200; since Linux 2.2)

在TCP保活打开的情况下,最后一次数据交换到TCP发送第一个保活探测包的间隔,即允许的持续空闲时长,或者说每次正常发送心跳的周期,默认值为7200s(2h)。

tcp_keepalive_probes (integer; default: 9; since Linux 2.2)

在tcp_keepalive_time之后,最大允许发送保活探测包的次数,到达此次数后直接放弃尝试,并关闭连接,默认值为9(次)。

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)

在tcp_keepalive_time之后,没有接收到对方确认,继续发送保活探测包的发送频率,默认值为75s。

sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

设置keepalive参数

vi /etc/sysctl.conf
# 数据交互空闲600秒后发送保活数据
net.ipv4.tcp_keepalive_time=600
# 如果没有收到对方确认,继续发送保活探测包,间隔为60秒
net.ipv4.net.ipv4.tcp_keepalive_intvl=60
# 最大允许发送保活探测包的次数,到达此次数后直接放弃尝试,并关闭连接
net.ipv4.net.ipv4.tcp_keepalive_probes=20
cat /etc/sysctl.conf
# 刷新配置
sysctl -p

查看TCP连接

netstat -anutp

参数含义:

-a 显示所有

-n 以ip形式显示当前建立的有效连接和端口

-u 显示UDP协议

-t 显示TCP协议

-p 显示对应PID与程序名

TCP KeepAlive报文格式

TCP KeepAlive探测报文是一种没有任何数据,同时ACK标志被置上的报文,报文中的序列号为上次发生数据交互时TCP报文序列号减1。比如上次本端和对端数据交互的最后时刻,对端回应给本端的ACK报文序列号为 N(即下次本端向对端发送数据,序列号应该为N),则本端向对端发送的保活探测报文序列号应该为 N-1。

TCP KeepAlive机制 的作用 是检测连接的有无(死活),但无法检测连接是否有效,如断网的时候。“连接有效”的定义 = 双方具备发送和接收消息的能力

KeepAlive机制无法代替心跳机制,需要在应用层自己实现心跳机制以检测长连接的有效性,从而高效维持长连接

Keep-Alive机制不会强制切断连接,如果连接存在但是一直不发生数据交互。Keep-Alive不会切断连接。而应用层实现的心跳检测 heartbeat_check 即便连接存在,但不产生数据交互的情况下,依然会强制切断连接。

IdleStateHandler

Netty 提供了一个名为 IdleStateHandler 的处理器,用于在一段时间内没有读取到数据或写入数据时触发事件。你可以通过将 IdleStateHandler 添加到 ChannelPipeline 中来实现自定义的空闲状态处理逻辑。这样就可以及时地检测连接的空闲状态,执行相应的处理操作,比如发送心跳消息或关闭连接。

定时任务

除了 IdleStateHandler 外,你还可以使用 Netty 提供的定时任务功能来实现保活机制。通过定时任务,你可以周期性地向对端发送心跳消息,以检测连接的状态。这种方式更加灵活,可以根据实际需求自定义心跳间隔和心跳消息内容。


相关文章
|
人工智能 监控 网络协议
【网络技术】心跳机制(入门讲解)
【网络技术】心跳机制(入门讲解)
|
监控 编译器 Windows
Qt5实现Windows平台串口通信
Qt5实现Windows平台串口通信
|
人工智能 安全 API
MCP vs 传统集成方案:REST API、GraphQL、gRPC的终极对比
作为一名长期关注AI技术发展的博主摘星,我深刻感受到了当前AI应用集成领域正在经历的巨大变革。随着Anthropic推出的Model Context Protocol(MCP,模型上下文协议)逐渐成熟,我们不得不重新审视传统的系统集成方案。在过去的几年中,REST API凭借其简单易用的特性成为了Web服务的标准选择,GraphQL以其灵活的数据查询能力赢得了前端开发者的青睐,而gRPC则以其高性能的特点在微服务架构中占据了重要地位。然而,当我们将视角转向AI应用场景时,这些传统方案都暴露出了一些局限性:REST API的静态接口设计难以适应AI模型的动态需求,GraphQL的复杂查询机制在处
778 0
MCP vs 传统集成方案:REST API、GraphQL、gRPC的终极对比
|
存储 NoSQL Java
Java Stream API:集合操作与并行处理
Stream API 是 Java 8 提供的集合处理工具,通过声明式编程简化数据操作。它支持链式调用、延迟执行和并行处理,能够高效实现过滤、转换、聚合等操作,提升代码可读性和性能。
1086 0
|
网络协议 安全 算法
路由协议(静态路由、RIP、OSPF、BGP)
本文介绍了四种常见的路由协议:静态路由、RIP、OSPF 和 BGP。静态路由由管理员手动配置,简单安全但缺乏动态性;RIP 是距离矢量协议,适合小型网络,实现简单但收敛慢且易产生环路;OSPF 基于链路状态算法,适用于中大型网络,快速收敛且无环路,但配置复杂;BGP 是路径矢量协议,主要用于自治系统间路由选择,策略性强、稳定性高,但配置难度大且依赖人工干预。根据网络规模和需求,可选择合适的路由协议。
1921 9
|
人工智能 安全 算法
HTTPS 的「秘钥交换 + 证书校验」全流程
HTTPS 通过“证书如身份证、密钥交换如临时暗号”的握手流程,实现身份认证与数据加密双重保障,确保通信安全可靠。
1546 0
|
人工智能 自然语言处理 运维
让搜索引擎“更懂你”:AI × Elasticsearch MCP Server 开源实战
本文介绍基于Model Context Protocol (MCP)标准的Elasticsearch MCP Server,它为AI助手(如Claude、Cursor等)提供与Elasticsearch数据源交互的能力。文章涵盖MCP概念、Elasticsearch MCP Server的功能特性及实际应用场景,例如数据探索、开发辅助。通过自然语言处理,用户无需掌握复杂查询语法即可操作Elasticsearch,显著降低使用门槛并提升效率。项目开源地址:<https://github.com/awesimon/elasticsearch-mcp>,欢迎体验与反馈。
4193 1
|
传感器 监控 物联网
Zabbix 7.0.0 发布,这些新特性很Nice!
【7月更文挑战第10天】
1510 1
Zabbix 7.0.0 发布,这些新特性很Nice!
|
内存技术
STM32CubeMX flash的使用
STM32CubeMX flash的使用
1796 10
|
机器学习/深度学习 数据采集 数据处理
多层感知机(MLP)解决二分类任务
分类任务: 开发一个神经网络,预测一氧化碳 (CO) 浓度是否超过某一阈值(CO(GT) 值的平均值)。这项任务涉及二元分类,即您的模型学会将实例分为两类:高于或低于阈值。阈值。要确定阈值,您必须首先计算CO(GT) 的平均值,其中不包括未知数据(缺失值)。然后,使用该阈值来预测网络预测的值是高于还是低于该阈值。但是您的网络应该能够处理缺失值。

热门文章

最新文章