心跳监听的方法、装置、设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种心跳监听的方法、装置、设备及存储介质。

背景技术

客户端需要心跳机制，让服务端感知到客户端是否在线或存活。客户端的软件系统可采用C/S架构(Client/Server，客户端/服务端架构)和/或B/S架构(Browser/Server，浏览器/服务器架构)。客户端系统采用以上任意一种架构都需要运用心跳机制来感知客户端的运行状态。例如基于客户端/服务端架构的视频会议场景中，参会人通过客户端入会，客户端非正常退出，服务端需要通过心跳机制感知客户端是否还在，如果不在，就提示主持人某参会人离开；在基于浏览器/服务器架构的系统，客户端运行在浏览器中，浏览器关闭，客户端是无法主动汇报退出的，只能通过心跳机制，让服务端感知客户端是否在线；另外，在即时聊天软件运行过程中，也是通过心跳机制感知用户是否处于在线状态的。

现有技术中服务端通过非关系型数据库键的过期事件来感知客户端是否在线，当服务端持续一段时间没有收到心跳数据时，非关系型数据库的键就触发了自动删除功能，并发送一个过期事件。服务端在监听心跳数据的同时对非关系型数据库的键的过期事件进行监听，当服务端收到过期事件，即表示这些过期事件对应的客户端离线。

然而，非关系型数据库键的过期事件是一个不可靠的事件，本身就容易发生丢失，因此会出现心跳数据监控不准确的问题，进一步导致客户端运行状态判断错误的情况。

发明内容

本申请提供一种心跳监听的方法、装置、设备及存储介质，用以解决心跳数据监控不准确的问题。

第一方面，本申请提供一种心跳监听方法，包括：

监测远程字典服务Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收所述心跳数据的时间戳，所述心跳数据包括：客户端标识；

根据设定的查询时间间隔启动服务器的查询任务，查询所述Redis中存储的所述心跳数据的时间戳是否超过设定阈值；

根据所述心跳数据的时间戳是否超过所述设定阈值，确定所述客户端的当前状态。根据所述心跳数据的时间戳是否超过所述设定阈值，确定所述客户端的当前状态。

第二方面，本申请提供一种心跳监听装置，包括：

监测模块，用于监测远程字典服务Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收所述心跳数据的时间戳，所述心跳数据包括：客户端标识；

查询模块，用于根据设定的查询时间间隔启动服务器的查询任务，查询所述Redis中存储的所述心跳数据的时间戳是否超过设定阈值；

确定模块，用于根据所述心跳数据的时间戳是否超过所述设定阈值，确定所述客户端的当前状态。

第三方面，本申请提供一种心跳监听设备，包括：

处理器，存储器，通信接口；

所述存储器用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行第一方面所述的心跳监听方法。

第四方面，本申请提供一种可读存储介质，其上存储有计算机程序，包括：

所述计算机程序被处理器执行时实现执行第一方面所述的心跳监听方法。

本申请提供的心跳监听的方法、装置、设备及存储介质，通过监测Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳，并且根据设定的查询时间间隔启动服务器的查询任务，查询Redis中存储的心跳数据的时间戳是否超过设定阈值，进一步确定客户端的当前状态。其中心跳数据的时间戳存储在Redis存储单元中，通过查询时间戳的方式可以使心跳状态的查询更加安全、稳定，实现了心跳监控更加准确的效果。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为是本申请第一实施例提供的心跳监听的方法流程示意图；

图2是本申请第二实施例提供的心跳监听的方法流程示意图；

图3是本申请第三实施例提供的心跳监听装置的结构示意图；

图4是本申请第三实施例提供的另一种心跳监听装置的结构示意图；

图5是本申请第四实施例提供的心跳监听设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

现有技术根据非关系型数据库键的过期事件对客户端的运行状态进行监控。当服务器持续一段时间没有收到心跳数据时，非关系型数据库的键就触发了自动删除功能，并发送一个过期事件；服务器在监听心跳数据的同时对非关系型数据库的键的过期事件进行监听，当服务器收到过期事件，即表示这些过期事件对应的客户端离线。但是，非关系型数据库键的过期事件本身是一个不可靠的事件，很容易发生丢失，因此会出现心跳数据监控不准确的问题，进一步导致客户端运行状态判断错误。

本申请提供的心跳监听的方法、装置、设备及存储介质，服务器首先通过监测Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳，其中，心跳数据的时间戳存储在Redis存储单元中。根据设定的查询时间间隔，查询Redis中存储的心跳数据的时间戳是否超过设定阈值，进一步根据时间戳的查询结果确定客户端的当前状态，其中，通过查询时间戳的方式可以使心跳状态的查询更加安全、稳定，可以实现心跳监控更加准确的效果。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1是本申请第一实施例提供的心跳监听的方法流程示意图。

如图1所示，本实施例提供的心跳监听的方法，执行主体为服务器，一般而言可以通过软件实现，或者硬件实现，或者软件和硬件相结合的方式实现。可以包括如下步骤：

步骤S101、监测远程字典服务Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接述心跳数据的时间戳，心跳数据包括：客户端标识。

具体地，在本实施例中，服务器接收客户端发送过来的心跳数据，经过服务器的解析，可以将心跳数据以一定的数据格式存入Redis的存储单元中，其中，心跳数据包括：客户端标识。同时服务器在接收心跳报文的同时还可以生成接收该心跳数据的时间戳，服务器接收心跳数据的时间戳也以一定的数据格式存入Redis的存储单元中。本实施例提供的心跳监听的过程，可以通过监测Redis存储单元中存储的心跳数据以及服务器接收心跳数据的时间戳来实现。

步骤S102、根据设定的查询时间间隔启动服务器的查询任务，查询Redis中存储的心跳数据的时间戳是否超过设定阈值。

其中，可以通过服务器的查询任务对Redis中存储的心跳数据的时间戳进行查询，判断其是否超过设定的阈值。具体地，可以根据设定的查询时间间隔启动服务器的查询任务，提取服务器的查询任务的启动时间，用服务器的查询任务的启动时间减去服务器的查询任务中设定的阈值，得到心跳数据时间戳的对比值；将查询任务查询到的Redis中存储的心跳数据的时间戳与心跳数据时间戳的对比值进行比较，判断查询任务查询到的Redis中存储的心跳数据的时间戳是否超过服务器的查询任务中设定阈值

步骤S103、根据心跳数据的时间戳是否超过设定阈值，确定客户端的当前状态。

具体地，通过步骤S102中根据设定的查询时间间隔启动的服务器的查询任务，可以得到心跳数据的时间戳与设定阈值的关系。当Redis中存储的心跳数据的时间戳超过服务器的查询任务中设定阈值时，Redis中存储的心跳数据的时间戳小于心跳数据时间戳的对比值，即该心跳数据中客户端标识对应的客户端在规定时间即心跳数据的上报频率要求的上报时间内未向服务端发送心跳数据；当Redis中存储的心跳数据的时间戳未超过服务器的查询任务中设定阈值时，Redis中存储的心跳数据的时间戳大于心跳数据时间戳的对比值，即该心跳数据中客户端标识对应的客户端在规定时间即心跳数据的上报频率要求的上报时间内向服务端发送了心跳数据。

由于服务器可以根据客户端在规定时间即心跳数据的上报频率要求的上报时间内是否向服务端发送了心跳数据对客户端的状态进行判断，因此可以根据心跳数据的时间戳是否超过设定阈值，确定客户端在规定时间即心跳数据的上报频率要求的上报时间内是否向服务端发送了心跳数据，进一步确定客户端的当前状态。

本实施例通过监测Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳，并且根据设定的查询时间间隔启动服务器的查询任务，查询Redis中存储的心跳数据的时间戳是否超过设定阈值，进一步确定客户端的当前状态。其中服务器通过查询时间戳的方式可以使心跳状态的查询更加安全、稳定，可以实现心跳监听更加准确的效果。

图2是本申请第二实施例提供的心跳监听的方法流程示意图。在图1所示实施例的基础上，本实施例在步骤S101之前增加了服务器接收客户端发送的报文、生成接收到心跳报文的时间戳以及将心跳数据和心跳数据时间戳存至Redis存储单元的描述；在步骤S103之后增加了服务器对客户端的状态提示；同时对步骤S102中服务器查询任务的具体设置及步骤S103中客户端当前状态的具体判断进行了进一步的描述。

如图2所示，本实施例提供的心跳监听的方法可以包括如下步骤：

步骤S201、服务器接收客户端发送的心跳报文，并对其解析和存储。

具体地，在上述步骤S101监测Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳之前，服务器还需要接收客户端发送的心跳报文；生成接收心跳报文的时间戳；将包括客户端标识的心跳数据及心跳报文的时间戳存储至Redis存储单元，以替换Redis存储单元已存储的客户端的上一次心跳数据和时间戳。

首先，服务器接收客户端发送的心跳报文，心跳报文中携带客户端标识。

其中，服务器可以同时接收多个客户端发送来的心跳数据，且同时对多个客户端的在线状态进行监控。在本实施例中，主要以一个客户端的心跳数据监控为例进行描述。具体地，客户端发送至服务器的心跳数据除了可以包括客户端标识外还可以包括少量其他和心跳数据相关的信息。服务端在接收到来自各客户端的心跳数据后，可以先对接收到的心跳数据进行解析处理，可以将心跳数据分解为：客户端标识和其他心跳数据相关的信息。其中，心跳数据相关的信息可以为空，也可以是有意义的数据，这取决于业务场景，不影响本实施例心跳监听方法的效率和性能。例如：对于远程电表监控场景，服务器可以通过远程电表定时发送的心跳数据判断远程电表的运行状态。同时，远程电表的心跳报文中也包括心跳数据相关的信息即少量在心跳数据上传同时与设备相关的一些数据，包括但不限于例如：电表读数、电表电压和报警数据等。服务器可以根据心跳数据相关的数据判断设备异常的原因，应用系统也可以根据心跳数据相关的数据进行信息收集。

然后，生成接收的心跳报文的时间戳。

其中，服务端在接收到心跳报文的同时，可以生成一个与心跳报文接收时间相对应的毫秒级的时间的整数值，该整数值记录服务器接收到该心跳数据的时间戳，即为心跳报文的时间戳或/和心跳数据的时间戳。

最后，将包括客户端标识的心跳数据及心跳报文的时间戳存储至Redis存储单元，以替换Redis存储单元已存储的客户端的上一次心跳数据和时间戳。

其中，存储系统Redis支持很多种类型的数据结构，例如：字符串string、链表list、集合set、有序集合sorted set和哈希hash等结构。在本实施例中，可选用存储系统Redis的有序集合sorted set数据结构存储客户端发送过来的心跳数据。可以将上述完成解析的心跳数据和心跳数据的时间戳存入至存储系统Redis的有序集合中。其中，存储系统Redis的有序集合可以分为多个字段对数据进行存储，在本实施例中，可以选用键Key、分数Score和成员Member字段存储完成解析的心跳数据和心跳数据的时间戳。具体地，可以将客户端标识存储至Redis存储单元的有序集合中的键Key值字段，可以将时间戳存储至有序集合中的分数Score值字段，还可以将上述其他心跳数据相关的信息存储至有序集合中的成员Member值字段。生成与此次心跳数据相关的Redis的有序集合。

以上存储过程针对的是服务器第一次接收到心跳数据的处理，由于客户端会每隔一段时间例如：10秒中重新上传一个心跳数据至服务器，因此当服务器再次收到客户端发送的新的心跳数据时，服务器中Redis存储单元中存储的心跳数据和心跳数据的时间戳相应的被更新，新一次的心跳数据和时间戳替换Redis存储单元已存储的客户端的上一次心跳数据和时间戳。因此，Redis存储单元中存储的是服务器接收到的最新一次心跳数据及其对应的心跳数据的时间戳。

步骤S202、设置服务器的查询任务，对Redis中存储的心跳数据的时间戳进行查询。

其中，在上述步骤S102根据设定的查询时间间隔启动服务器的查询任务，查询Redis中存储的心跳数据的时间戳是否超过设定阈值之前，还需要对查询任务进行设置，该设置主要包括为服务器的查询任务进行参数配置，参数包括：查询任务的启动时间、查询时间间隔以及设定阈值。

具体地，根据业务场景要求及业务需要设置查询任务的启动时间和查询时间间隔。其中，查询任务的启动时间可以设置为一个时间点例如：9点钟，当系统到达查询任务的启动时间时查询任务启动，查询任务对有序集合中的分数进行查询。另外，可以通过设置查询任务中查询时间间隔的方式，对有序集合的分数在一次查询任务中进行多次查询，查询任务中分数Score查询的时间间隔可以设置为一个时间段例如：3分钟。

另外，服务器的查询任务中设定的阈值是判断客户端心跳状态的重要参数，其中，服务器的查询任务中设定的阈值应大于客户端心跳数据的上报频率即心跳数据上传的时间间隔。例如：如果客户端心跳数据每隔10秒钟上报一次至服务端，那么服务器的查询任务中设定的阈值需要设置为大于10秒的数值。

步骤S203、根据设定的查询时间间隔启动服务器的查询任务，查询Redis存储的心跳数据的时间戳是否超过设定阈值；

具体地，由于Redis中的Score字段存储的是最新接收到的来自客户端的心跳数据的时间戳，因此，本实施例中服务器启动的查询任务可以通过分数Score字段查询的方式对存储系统Redis的有序集合进行分析。其中，系统在到达启动时间的时候启动查询任务，并且根据设定的查询时间间隔对Redis中的分数Score字段存储的心跳数据的时间戳进行多次查询，同时根据查询任务的启动时间和查询时间间隔可以得到多个查询任务的启动时间。

在本实施例中，以有序集合的一次分数查询即一次查询任务为例，查询Redis存储的心跳数据的时间戳，并判断其是否超过设定阈值。如步骤S102中所描述的方法，可以得到心跳数据时间戳的对比值。如果Redis中存储的心跳数据的时间戳小于心跳数据时间戳的对比值，Redis中存储的心跳数据的时间戳超过服务器的查询任务中设定阈值，如果Redis中存储的心跳数据的时间戳大于心跳数据时间戳的对比值，Redis中存储的心跳数据的时间戳未超过服务器的查询任务中设定阈值。

步骤S204、根据心跳数据的时间戳是否超过设定阈值，确定客户端的当前状态。

具体地，若心跳数据的时间戳超过设定阈值，则确定客户端处于离线状态。即当心跳数据的时间戳未超过设定阈值，即当Redis中存储的心跳数据的时间戳小于心跳数据时间戳的对比值时，判断该心跳数据中客户端标识对应的客户端在规定时间即心跳数据的上报频率要求的上报时间内向服务端发送了心跳数据，因此该客户端处于在线状态；若心跳数据的时间戳未超过设定阈值，则确定客户端处于在线状态。即当心跳数据的时间戳超过设定阈值，即当Redis中存储的心跳数据的时间戳大于心跳数据时间戳的对比值时，判断该心跳数据中客户端标识对应的客户端在规定时间即心跳数据的上报频率要求的上报时间内未向服务端发送心跳数据，因此该客户端处于离线状态。

步骤S205、服务器将客户端的离线状态提示发送至对应客户端的业务系统，触发离线的后续业务操作。

具体地，当服务器确定客户端的当前状态后，对于处于离线状态的客户端，提取其客户端标识，生成客户端离线提示，并将其发送至对应的客户端的业务系统中。客户端业务系统在接收到服务器发送的客户端离线状态提示后，可以启动离线业务操作。

其中，客户端业务系统启动的离线业务操作可以包括但不限于：发送离线消息，清理临时数据等操作。

本实施例在监测Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳之前增加了服务器接收客户端发送的心跳报文，并对其解析和存储的描述。其中，心跳数据中解析出来的心跳数据的其他信息可能包括与客户端有关的其他信息，服务器在对客户端的心跳进行监听的同时还可以对该客户端有关的其他信息进行分析。且本实施例通过查询任务主动查询的方式进行心跳数据的监控，并且可以根据业务场景及需要对查询任务的相关参数进行设置，使得心跳监听更加符合客户端的业务特点，提高了心跳监听的准确性。

图3是本申请第三实施例提供的一种心跳监听装置的结构示意图。

如图3所示，本实施例的心跳监听装置30包括：监测模块31、查询模块32、确定模块33。

监测模块31，用于监测远程字典服务Redis存储单元中存储的服务器最近一次接收的客户端的心跳数据以及服务器接收心跳数据的时间戳，心跳数据包括：客户端标识及心跳数据的其他信息；

查询模块32，用于根据设定的查询时间间隔，查询Redis中存储的心跳数据的时间戳是否超过设定阈值；

确定模块33，用于根据心跳数据的时间戳是否超过设定阈值，确定客户端的当前状态。

其中，确定模块33具体用于：若心跳数据的时间戳超过设定阈值，则确定客户端处于离线状态；若心跳数据的时间戳未超过设定阈值，则确定客户端处于在线状态。

在上述心跳监听装置的基础上，心跳监听装置30还包括：接收模块34、生成模块35和处理模块36，本实施例提供的另一种心跳监听装置的结构示意图参见图4

接收模块34，用于接收客户端发送的心跳报文，心跳报文中携带客户端标识；

生成模块35，用于接收心跳报文的时间戳；

处理模块36，用于将包括客户端标识的心跳数据及心跳报文的时间戳存储至Redis存储单元，以替换Redis存储单元已存储的客户端的上一次心跳数据和时间戳。本实施例提供的装置，可用于执行上述方法实施例图1和图2的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图5是本申请第四实施例提供的一种心跳监听设备的结构示意图。

如图5所示，本实施例的心跳监听设备50包括：处理器51，存储器52，通信接口53。

存储器52用于存储处理器的可执行指令；

其中，处理器51配置为经由执行可执行指令来执行上述方法实施例图1和图2任一项的心跳监听方法。

本申请实施例还提供一种可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现执行上述方法实施例图1和图2任一项的心跳监听方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。