轮询与心跳机制

﹏ヽ暗。殇╰゛Y 2022-08-07 09:44 183阅读 0赞

上一篇内容参见（）

在上一篇文章中提到的缓存内网服务端会话信息中，外网服务端保存内网服务端会话的有效性以及平台上监控所有内网服务端的网络状况，模仿心跳机制实现，这里在做一点叙诉，关于思路和具体实现。  
  
  
 在很多的平台应用中，都有这样的需求，平台内包括多个子系统或者属于其管控范围内的其他平台，需要对这些系统进行统一的监控，来查看当前的运行状态或者其他运行信息，我们的应用也有这样的一个情况，需要再外网服务端（平台）上监控，其下运行的多个内网服务端的网络状况，查阅了写资料后确立了2种可实现的方式。  
 1：轮询机制

2：心跳机制

先简单介绍一下，  
 轮询：概括来说是服务端定时主动的去与要监控状态的客户端（或者叫其他系统）通信，询问当前的某种状态，客户端返回状态信息，客户端没有返回或返回错误、失效信息、则认为客户端已经宕机，然后服务端自己内部把这个客户端的状态保存下来（宕机或者其他），如果客户端正常，那么返回正常状态，如果客户端宕机或者返回的是定义的失效状态那么当前的客户端状态是能够及时的监控到的，如果客户端宕机之后重启了那么当服务端定时来轮询的时候，还是可以正常的获取返回信息，把其状态重新更新。

心跳：最终得到的结果是与轮询一样的但是实现的方式有差别，心跳不是服务端主动去发信息检测客户端状态，而是在服务端保存下来所有客户端的状态信息，然后等待客户端定时来访问服务端，更新自己的当前状态，如果客户端超过指定的时间没有来更新状态，则认为客户端已经宕机或者其状态异常。

心跳机制与轮询的比较，在我们的应用中，采用的是心跳，这样一是避免服务端的压力，二是灵活好控制，上一篇文章中提到过，我们的外网服务端（服务端）不知道内网服务端（客户端）的地址，有虽然有保存客户端的socket会话，但是客户端宕机会话就失效了。所以只能等着他主动来报告状态。

在来说一下实现方式，这个很简单，就是一个思路问题。

首先，客户端（内网服务端）启动后，带着自己的标识符与服务端建立socket连接，服务端缓存下来对应信息（上一篇文章中已经实现过了），然后在通过socket流，定时发送当前信息消息到服务端（外网服务器端）某个接口，服务端收到后更新当前的客户端的状态，比如（会话地址，标识符，网络的活跃状态，连接时间，心跳时间），本次来更新的时间就是心跳时间，然后服务端还有一个定时器，定时检查所有缓存的客户端会话集合，将其中心跳时间与当前时间进行对比，如果超过指定的时间还没有来更新则认为该客户端的网络出现异常或者宕机，然后更新该客户端的网络状态。