轮询与心跳机制
2015-03-29 20:13
190 查看
上一篇内容参见()
在上一篇文章中提到的缓存内网服务端会话信息中,外网服务端保存内网服务端会话的有效性以及平台上监控所有内网服务端的网络状况,模仿心跳机制实现,这里在做一点叙诉,关于思路和具体实现。
在很多的平台应用中,都有这样的需求,平台内包括多个子系统或者属于其管控范围内的其他平台,需要对这些系统进行统一的监控,来查看当前的运行状态或者其他运行信息,我们的应用也有这样的一个情况,需要再外网服务端(平台)上监控,其下运行的多个内网服务端的网络状况,查阅了写资料后确立了2种可实现的方式。
1:轮询机制
2:心跳机制
先简单介绍一下,
轮询:概括来说是服务端定时主动的去与要监控状态的客户端(或者叫其他系统)通信,询问当前的某种状态,客户端返回状态信息,客户端没有返回或返回错误、失效信息、则认为客户端已经宕机,然后服务端自己内部把这个客户端的状态保存下来(宕机或者其他),如果客户端正常,那么返回正常状态,如果客户端宕机或者返回的是定义的失效状态那么当前的客户端状态是能够及时的监控到的,如果客户端宕机之后重启了那么当服务端定时来轮询的时候,还是可以正常的获取返回信息,把其状态重新更新。
心跳:最终得到的结果是与轮询一样的但是实现的方式有差别,心跳不是服务端主动去发信息检测客户端状态,而是在服务端保存下来所有客户端的状态信息,然后等待客户端定时来访问服务端,更新自己的当前状态,如果客户端超过指定的时间没有来更新状态,则认为客户端已经宕机或者其状态异常。
心跳机制与轮询的比较,在我们的应用中,采用的是心跳,这样一是避免服务端的压力,二是灵活好控制,上一篇文章中提到过,我们的外网服务端(服务端)不知道内网服务端(客户端)的地址,有虽然有保存客户端的socket会话,但是客户端宕机会话就失效了。所以只能等着他主动来报告状态。
在来说一下实现方式,这个很简单,就是一个思路问题。
首先,客户端(内网服务端)启动后,带着自己的标识符与服务端建立socket连接,服务端缓存下来对应信息(上一篇文章中已经实现过了),然后在通过socket流,定时发送当前信息消息到服务端(外网服务器端)某个接口,服务端收到后更新当前的客户端的状态,比如(会话地址,标识符,网络的活跃状态,连接时间,心跳时间),本次来更新的时间就是心跳时间,然后服务端还有一个定时器,定时检查所有缓存的客户端会话集合,将其中心跳时间与当前时间进行对比,如果超过指定的时间还没有来更新则认为该客户端的网络出现异常或者宕机,然后更新该客户端的网络状态。
在上一篇文章中提到的缓存内网服务端会话信息中,外网服务端保存内网服务端会话的有效性以及平台上监控所有内网服务端的网络状况,模仿心跳机制实现,这里在做一点叙诉,关于思路和具体实现。
在很多的平台应用中,都有这样的需求,平台内包括多个子系统或者属于其管控范围内的其他平台,需要对这些系统进行统一的监控,来查看当前的运行状态或者其他运行信息,我们的应用也有这样的一个情况,需要再外网服务端(平台)上监控,其下运行的多个内网服务端的网络状况,查阅了写资料后确立了2种可实现的方式。
1:轮询机制
2:心跳机制
先简单介绍一下,
轮询:概括来说是服务端定时主动的去与要监控状态的客户端(或者叫其他系统)通信,询问当前的某种状态,客户端返回状态信息,客户端没有返回或返回错误、失效信息、则认为客户端已经宕机,然后服务端自己内部把这个客户端的状态保存下来(宕机或者其他),如果客户端正常,那么返回正常状态,如果客户端宕机或者返回的是定义的失效状态那么当前的客户端状态是能够及时的监控到的,如果客户端宕机之后重启了那么当服务端定时来轮询的时候,还是可以正常的获取返回信息,把其状态重新更新。
心跳:最终得到的结果是与轮询一样的但是实现的方式有差别,心跳不是服务端主动去发信息检测客户端状态,而是在服务端保存下来所有客户端的状态信息,然后等待客户端定时来访问服务端,更新自己的当前状态,如果客户端超过指定的时间没有来更新状态,则认为客户端已经宕机或者其状态异常。
心跳机制与轮询的比较,在我们的应用中,采用的是心跳,这样一是避免服务端的压力,二是灵活好控制,上一篇文章中提到过,我们的外网服务端(服务端)不知道内网服务端(客户端)的地址,有虽然有保存客户端的socket会话,但是客户端宕机会话就失效了。所以只能等着他主动来报告状态。
在来说一下实现方式,这个很简单,就是一个思路问题。
首先,客户端(内网服务端)启动后,带着自己的标识符与服务端建立socket连接,服务端缓存下来对应信息(上一篇文章中已经实现过了),然后在通过socket流,定时发送当前信息消息到服务端(外网服务器端)某个接口,服务端收到后更新当前的客户端的状态,比如(会话地址,标识符,网络的活跃状态,连接时间,心跳时间),本次来更新的时间就是心跳时间,然后服务端还有一个定时器,定时检查所有缓存的客户端会话集合,将其中心跳时间与当前时间进行对比,如果超过指定的时间还没有来更新则认为该客户端的网络出现异常或者宕机,然后更新该客户端的网络状态。
相关文章推荐
- netty4 如何建立心跳机制
- 从微信谈起,如何优化互联网APP心跳机制
- Oracle RAC/Clusterware 多种心跳heartbeat机制介绍 RAC超时机制分析
- Nginx中的upstream轮询机制介绍
- 为什么JAVA要提供 wait/notify 机制?是为了避免轮询带来的性能损失
- 定时轮询任务 比如用于心跳
- Android长连接心跳机制
- 心跳保活---TeamTalk心跳保活机制分析
- Linux socket编程的心跳机制总结
- Hadoop源码分析之心跳机制
- HDFS源码分析(五)-----节点注册与心跳机制
- 分布式消息队列RocketMQ源码分析之2 -- Broker与NameServer心跳机制
- dubbo服务提供者注册后为什么要有心跳机制
- 网络通信中的心跳机制的实现! 推荐
- nova的服务心跳机制和服务状态监控机制的实现
- 您还有心跳吗?超时机制分析(java)
- JS中的异步以及事件轮询机制
- Go语言 Go的网络轮询及IO机制
- 服务器实现心跳机制的两种策略