一种基于云边端架构的终端保活管理方法及装置

摘要

本说明书一个或多个实施例提供一种基于云边端架构的终端保活管理方法及装置，其中，该云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平台和位于底层的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管理；该方法应用于任一边缘管理平台，包括：接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新；按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

权利要求

1.一种基于云边端架构的终端保活管理系统，所述云边端架构包括：顶层的云端控制中心、位于中间层的多个边缘管理平台和位于底层的已注册终端；在每一边缘管理平台中，构建有包含多个单位时间段的保活状态队列，与任一单位时间段对应的存储容器被作为失活存储容器、区别于所述任一单位时间段的其他单位时间段所对应的存储容器被确定为未失活存储容器；其中，

所述已注册终端，向所属域对应的边缘处理平台发送心跳信息，以使相应的边缘处理平台对相应的已注册终端的保活状态进行更新；其中，任一边缘管理平台，对所辖域内的已注册终端的保活状态进行更新，包括：确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中；在接收到任一已注册终端发送的心跳信息之前，所述任一已注册终端的设备标识被所述任一边缘管理平台存储于所述失活存储容器中；

所述多个边缘管理平台，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，包括：获取存储于所述失活存储容器中的设备标识，以将获取到的设备标识所对应的已注册终端的保活状态确定为失活状态；和/或，获取存储于所述未失活存储容器中的设备标识，以将获取到的设备标识对应的已注册终端的保活状态确定为未失活状态；以及，将生成的域内聚合结果上传至所述云端控制中心；

所述云端控制中心，根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

2.根据权利要求1所述的终端保活管理系统，所述保活状态队列为环形队列；

所述任一边缘管理平台，创建对应于所述环形队列的指针，所述指针在每一周期内，从所述任一单位时间段开始按照预设顺序依次指向下一个单位时间段；

所述任一边缘管理平台确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中，包括：当接收到所述心跳信息时，确定出所述指针所指的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中。

3.根据权利要求2所述的终端保活管理系统，所述任一边缘管理平台，构建位置存储表，所述位置存储表记录有各个已注册终端的设备标识所处的存储容器；

所述任一边缘管理平台将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中，包括：在接收到任一已注册终端发送的心跳信息的情况下，根据所述位置存储表确定出存储有所述任一已注册终端的设备标识的存储容器，并将存储于确定出的存储容器中的所述任一已注册终端的设备标识删除、在所述指针当前所指的存储容器中添加所述任一已注册终端的设备标识。

4.根据权利要求3所述的终端保活管理系统，所述任一边缘管理平台还用于：在每一周期内，统计所辖域内各个已注册终端发送心跳信息的次数、以及所述各个已注册终端各自发送的若干心跳信息所处单位时间段的分布情况，以根据统计得到的发送次数和分布情况确定出各个已注册终端的健康度。

5.一种基于云边端架构的终端保活管理方法，所述云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平台和位于底层的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管理；所述方法应用于任一边缘管理平台，包括：构建包含多个单位时间段的保活状态队列，并将与任一单位时间段对应的存储容器作为失活存储容器、将区别于所述任一单位时间段的其他单位时间段所对应的存储容器确定为未失活存储容器；其中，在接收到任一已注册终端发送的心跳信息之前，所述任一已注册终端的设备标识被所述任一边缘管理平台存储于所述失活存储容器中；

接收所辖域内的已注册终端发送的心跳信息；以及，根据所述心跳信息对相应的已注册终端的保活状态进行更新，包括：确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中；

按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，包括：获取存储于所述失活存储容器中的设备标识，以将获取到的设备标识所对应的已注册终端的保活状态确定为失活状态；和/或，获取存储于所述未失活存储容器中的设备标识，以将获取到的设备标识对应的已注册终端的保活状态确定为未失活状态；

将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

6.根据权利要求5所述的方法，所述保活状态队列为环形队列；

所述方法还包括：生成对应于所述环形队列的指针，所述指针在每一周期内，从所述任一单位时间段开始按照预设顺序依次指向下一个单位时间段；

所述确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中，包括：当接收到所述心跳信息时，确定出所述指针所指的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中。

7.根据权利要求6所述的方法，

还包括：构建位置存储表，所述位置存储表记录有各个已注册终端的设备标识所处的存储容器；

所述将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中，包括：在接收到任一已注册终端发送的心跳信息的情况下，根据所述位置存储表确定出存储有所述任一已注册终端的设备标识的存储容器，并将存储于确定出的存储容器中的所述任一已注册终端的设备标识删除、在所述指针当前所指的存储容器中添加所述任一已注册终端的设备标识。

8.根据权利要求7所述的方法，还包括：在每一周期内，统计所辖域内各个已注册终端发送心跳信息的次数、以及所述各个已注册终端各自发送的若干心跳信息所处单位时间段的分布情况，以根据统计得到的发送次数和分布情况确定出各个已注册终端的健康度。

9.根据权利要求5所述的方法，还包括：在生成所述域内聚合结果之后，将存储于未失活存储容器中的设备标识更新至所述失活存储容器中，以将上一周期中除处于失活状态以外的已注册终端初始化为下一周期中的已注册终端。

10.根据权利要求5所述的方法，还包括：在生成所述域内聚合结果之后，将上一周期中请求注册的终端设备的设备标识存储至所述失活存储容器中，以将所述终端设备作为下一周期中新增的已注册终端；

将新增的已注册终端的设备标识发送至所述云端控制中心，以使所述云端控制中心对维护的全局所有已注册终端进行更新。

11.根据权利要求5所述的方法，还包括：在生成所述域内聚合结果之后，注销处于失活状态的已注册终端；

将注销的已注册终端的设备标识发送至所述云端控制中心，以使所述云端控制中心对维护的全局所有已注册终端进行更新。

12.一种基于云边端架构的终端保活管理装置，所述云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平台和位于底层的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管理；所述装置应用于任一边缘管理平台，包括：构建单元，构建包含多个单位时间段的保活状态队列，并将与任一单位时间段对应的存储容器作为失活存储容器、将区别于所述任一单位时间段的其他单位时间段所对应的存储容器确定为未失活存储容器；

更新单元，接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新，包括：确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中；其中，在接收到任一已注册终端发送的心跳信息之前，所述任一已注册终端的设备标识被所述任一边缘管理平台存储于所述失活存储容器中；

聚合单元，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，包括：获取存储于所述失活存储容器中的设备标识，以将获取到的设备标识所对应的已注册终端的保活状态确定为失活状态；和/或，获取存储于所述未失活存储容器中的设备标识，以将获取到的设备标识对应的已注册终端的保活状态确定为未失活状态；

所述聚合单元还被用于：将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

13.一种电子设备，包括：

处理器；

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

其中，所述处理器通过运行所述可执行指令以实现如权利要求5‑11中任一项所述的方法。

14.一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求5‑11中任一项所述方法的步骤。

说明书

一种基于云边端架构的终端保活管理方法及装置

技术领域

[0001] 本说明书一个或多个实施例涉及终端技术领域，尤其涉及一种基于云边端架构的终端保活管理方法及装置。

背景技术

[0002] 为了保证业务的正常执行，对于业务的服务端而言需要知晓各个终端的保活状态，进而确定相应终端的状态是否能够对业务进行处理。服务端唯有在确定终端的状态处
于未失活状态的情况下，才会将业务交由其处理，以避免下发的业务无法处理的情况。

[0003] 在相关技术中，对于包含海量终端的若干区域，所有终端的保活状态均由统一的云端控制中心进行维护。具体的，若干区域中的所有终端均通过向该云端控制中心发送心
跳信息的方式，告知云端控制中心自身并未失活，相应的，云端控制中心则可以根据接收到
各个终端发送的心跳信息对维护的全局所有终端的保活状态进行更新。

发明内容

[0004] 有鉴于此，本说明书一个或多个实施例提供一种基于云边端架构的终端保活管理方法及装置。

[0005] 为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

[0006] 根据本说明书一个或多个实施例的第一方面，提出了一种基于云边端架构的终端保活管理系统，所述云边端架构包括：顶层的云端控制中心、位于中间层的多个边缘管理平
台和位于底层的已注册终端；其中，

[0007] 所述已注册终端，向所属域对应的边缘处理平台发送心跳信息，以使相应的边缘处理平台对相应的已注册终端的保活状态进行更新；

[0008] 所述边缘管理平台，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至所述云端控制中心；

[0009] 所述云端控制中心，根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0010] 根据本说明书一个或多个实施例的第二方面，提出了一种基于云边端架构的终端保活管理方法，所述云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平
台和位于底层的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管
理；所述方法应用于任一边缘管理平台，包括：

[0011] 接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新；

[0012] 按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平台分别上传
的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0013] 根据本说明书一个或多个实施例的第三方面，提出了一种基于云边端架构的终端保活管理装置，所述云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平
台和位于底层的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管
理；所述方法应用于任一边缘管理平台，包括：

[0014] 更新单元，接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新；

[0015] 聚合单元，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平
台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0016] 根据本说明书一个或多个实施例的第四方面，提出了一种电子设备，包括：

[0017] 处理器；

[0018] 用于存储处理器可执行指令的存储器；

[0019] 其中，所述处理器通过运行所述可执行指令以实现如第二方面所述的方法。

[0020] 根据本说明书一个或多个实施例的第五方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第二方面所述方法的步骤。

附图说明

[0021] 图1是一示例性实施例提供的一种基于云边端架构的保活管理系统的示意图。

[0022] 图2是一示例性实施例提供的一种基于云边端架构的保活管理方法的流程图。

[0023] 图3是一示例性实施例提供的一种基于云边端架构的终端保活管理方法的交互图。

[0024] 图4是一示例性实施例提供的一种应用于边缘管理平台的保活状态更新方法的流程图。

[0025] 图5是一示例性实施例提供的一种环形队列及其相关对象的示意图。

[0026] 图6是一示例性实施例提供的一种应用于边缘管理平台的保活状态聚合方法的流程图。

[0027] 图7是一示例性实施例提供的一种设备的结构示意图。

[0028] 图8是一示例性实施例提供的一种基于云边端架构的终端保活管理装置的框图。

具体实施方式

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

[0030] 需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更
多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进
行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行
描述。

[0031] 对于作为业务分发方的服务端而言，在发放业务之前，通常都会预先获取作为业务发放对象的终端的保活状态，且仅在确定终端处于未失活状态时，才将业务数据传输至
相应的终端，以由其进行处理。通过该方式，能够有效避免将业务数据传输至处于失活状态
的终端，而导致业务数据无法被正常处理的问题。

[0032] 在相关技术中，若干区域中包含的所有终端的保活状态都由唯一的云端控制中心进行统一维护，以使各个服务器在需要发放业务时，可以从该云端控制中心处获取作为业
务发放对象的终端的保活状态。

[0033] 在实际应用中，各个区域中的终端通过向上述云端控制中心发送心跳信息的方式，通知该云端控制中心自身尚处于未失活状态；而云端控制中心则会基于接收到的各个
终端发送的心跳信息，对自身维护的全局终端保活状态进行更新。

[0034] 应当理解的是，由于相关技术中的终端通过直接向云端控制中心发送心跳信息的方式，使云端控制中心对相应终端的保活状态进行更新，而云端控制中心接收到的心跳信
息可能由多个区域的海量终端发送，使得云端控制中心在对全量终端保活状态进行更新的
过程中，负载极高，不仅容易出现维护错误的情况，还极易造成云端控制中心的故障。

[0035] 为此，本说明书提出了一种基于云边端架构的终端保活管理系统，以解决云端控制中心直接接收并处理海量终端发送的心跳信息，而导致云端控制中心负载过高的问题。

[0036] 图1是一示例性实施例提供的一种基于云边端架构的终端保活管理系统。如图1所示，该终端保活管理系统包括：顶层101的云端控制中心、位于中间层102的多个边缘管理平
台和位于底层103的已注册终端；其中，

[0037] 所述已注册终端，向所属域对应的边缘处理平台发送心跳信息，以使相应的边缘处理平台对相应的已注册终端的保活状态进行更新；

[0038] 所述多个边缘管理平台，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至所述云端控制中心；

[0039] 所述云端控制中心，根据各个边缘管理平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0040] 由上述介绍可知，相关技术中之所以存在云端控制中心负载过高的问题，是由于相关技术中位于各个区域的海量终端，均直接将心跳信息发送至云端控制中心，由云端控
制中心对所有终端的全量保活状态进行更新而导致的。

[0041] 有鉴于此，本说明书在云端控制中心与海量终端之间新增了包含多个边缘管理平台的中间层，其中，每一边缘管理平台对应有相应的管辖区域，以负责所辖域内的所有已注
册终端的保活状态更新，且每一边缘处理平台可以按照预设周期对所辖域内所有已注册终
端的保活状态进行聚合，并将聚合结果上传至云端控制中心，以由云端控制中心对全局所
有已注册终端的全量保活状态进行维护。

[0042] 应当理解的是，由于本说明书中按照终端所属区域，为位于底层的已注册终端配置了相应的边缘管理平台，使得相关技术中需要由云端控制中心统一负责的保活状态更新
操作，被分散至各个边缘处理平台分别执行，避免了云端控制中心需要根据全局所有已注
册终端发送的心跳信息，对全局所有终端的保活状态进行更新，而导致的负载过高的问题。

[0043] 在实际操作中，可以如图1所示，假设全局所有已注册终端被划分为3个区域，且为每一区域均配置有对应的一个边缘管理平台，即图1中位于中间层102的Edge1 3，而每一边
~
缘管理平台则负责接收所辖域内的各个已注册终端发送的心跳信息，以对相应已注册终端
的保活状态进行更新，例如，图1中的Dev11 13可以向Edge1发送心跳信息，以使Edge1对
~
Dev11 13的保活状态进行更新；而Dev21 22则可以向Edge2发送心跳信息，以使Edge2对
~ ~
Dev21 22的保活状态进行更新；Dev31 33也是类似，在此不再赘述。相应的，边缘管理平台
~ ~
则可以按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，例如，图1中的
Edge1在某一周期结束时，可以对Dev11 13的保活状态进行聚合，并将聚合结果上传至
~
Cloud，以使Cloud对相应的已注册终端的保活状态进行更新；图1中的Edge2和3也是类似，
在此不再赘述。

[0044] 需要声明的是，在上述举例仅是示意性的。在实际应用中，既可以为各个区域均配置一边缘管理平台，也可以为多个区域配置同一边缘管理平台的所辖区域，例如，可以将
Edge1配置为Dev11 13和Dev21 11对应的边缘管理平台、将Edge3配置为Dev31 33的边缘管
~ ~ ~
理平台，具体如何为不同区域的终端配置边缘管理平台可以由本领域技术人员根据实际情
况确定，本说明书对此不作限制。除此之外，在实际应用中，每一区域所包含的终端通常是
海量的，上述仅仅是以每一区域包含2 3个终端为例进行介绍。
~

[0045] 还需声明的是，上述已注册终端指的是：预先将自身设备信息注册至所属区域对应的边缘管理平台中的终端设备。在实际操作中，各个区域中的终端设备可以向自身所属
区域对应的边缘管理平台发送注册请求的方式，将自身设备信息提供至该边缘管理平台，
以完成注册。在本说明书中，边缘管理平台唯有在终端完成注册，成为已注册终端之后，才
会基于相应终端发送的心跳信息，对该终端的保活状态进行更新。

[0046] 在相关技术中，除了存在上述云端控制中心负载过高的问题以外，还存在保活状态更新效率低下的问题。在实际应用中，相关技术中的云端控制中心在接收到各个已注册
终端发送的心跳信息后，会记录接收到各个已注册终端发送的心跳信息的时刻，并按照预
设周期遍历记录的接收到所有已注册终端上一次发送的心跳信息的时刻，进而判断接收到
各个已注册终端上一次发送心跳信息的时刻与该遍历时刻的时间间隔，是否超出预设容忍
时长，若超出则确定相应的已注册终端处于失活状态；否则，确定相应的已注册终端处于未
失活状态。

[0047] 可见，在相关技术中，不仅需要记录接收到所有已注册终端发送的心跳信息的时刻，且每一次对已注册终端的保活状态进行更新时，均需遍历记录的接收到所有已注册终
端发送的心跳信息的时刻，一方面，占用了大量处理资源用于遍历，进一步增加了云端控制
中心的负载；另一方面，由于遍历花费时间较长，不仅降低了保活状态更新操作的效率，且
很可能出现遍历时长与预设周期较为接近（在全局已注册终端数量较多时，甚至超出预设
周期时长），而导致部分已注册终端的保活状态更新错误的情况。

[0048] 有鉴于此，本说明书在将“根据接收到的心跳信息，更新保活状态”的操作转移至中间层的边缘处理平台的基础上，进一步对“根据心跳信息对保活状态进行更新”的操作进
行了改进，以解决相关技术中，由于需要执行遍历操作，而导致的更新效率较低、甚至出现
更新错误的问题。

[0049] 具体的，本说明书中的每一边缘管理平台中可以配置有失活存储容器和未失活存储容器。其中，对于任一边缘管理平台，在未接收到所辖域内的已注册终端的心跳信息的情
况下，已注册终端的设备标识被存储于上述失活存储容器中；而在接收到该已注册终端发
送的心跳信息的情况下，便将该已注册终端的设备标识更新至上述未失活存储容器中。通
过该方式，即可统计该任一边缘管理平台所辖域内所有已注册终端在每一周期内发送心跳
信息的情况，具体的，当任一周期结束时，该任一边缘管理平台即可确定出所辖域内所有已
注册终端的设备标识的存储位置，以根据确定出的存储位置得出上述聚合结果，其中，若某
一已注册终端的设备标识仍存储于失活存储容器中，则证明在上一周期中并未接收到该已
注册终端发送的心跳信息，因此，可以将其保活状态确定为失活状态；相反的，若某一已注
册终端的设备标识被存储于未失活存储容器中，则证明在上一周期中接收到了至少一次该
已注册终端发送的心跳信息，因此，可以将其保活状态确定为未失活状态。

[0050] 可见，本说明书通过引入失活存储容器和未失活存储容器的方式，使得本说明书在任一周期结束时，只需根据两存储容器中分别存储的设备标识，即可确定出所辖域内各
个已注册终端的保活状态，并将确定的所有已注册终端的保活状态作为聚合结果上传至云
端控制中心，避免了相关技术中“需要记录接收到各个已注册终端发送的心跳信息的时刻”
的操作，以及“在需要对全局所有已注册终端的保活状态进行更新时，需要进行遍历”的情
况，提高了保活状态更新操作的执行效率。

[0051] 需要声明的是，本说明书可以无需确定所有已注册终端的设备标识的存储位置。例如，可以仅获取存储于失活存储容器中的设备标识，并将获取到的设备标识对应的已注
册终端的保活状态确定为失活状态，而将除获取到的设备标识以外的其他设备标识对应的
已注册终端的保活状态确定为未失活状态；相应的，也可以仅获取存储于未失活存储容器
中的设备标识，并将获取到的设备标识对应的已注册终端的保活状态确定为未失活状态，
而将除获取到的设备标识以外的其他设备标识对应的已注册终端的保活状态确定为失活
状态。

[0052] 该举例中的聚合方式相当于仅获取其中某一存储容器中的设备标识，并将该存储容器所对应的保活状态确定为获取到的设备标识所对应的已注册终端的保活状态，而将未
获取到的设备标识所对应的已注册终端的保活状态默认为另一存储容器所对应的保活状
态。当然，在实际应用中，可能出现某些意外情况，而导致两存储容器分别存储的设备标识
的合集并非所有已注册终端的设备标识，因此，也可以分别获取两存储容器中保存的设备
标识，以根据从两存储容器中分别获取的设备标识确定各个已注册终端的保活状态。

[0053] 在本说明书中，还可以包含多个不同的未失活存储容器，并在各个未失活存储容器和不同的单位时间段之间建立映射关系，以记录接收到各个已注册终端发送的心跳信息
时所处的单位时间段。具体的，边缘管理平台可以构建包含多个单位时间段的保活状态队
列，并在多个单位时间段与多个存储容器之间建立映射关系，其中，可以将与任一单位时间
段对应的存储容器作为上述失活存储容器，而将其余单位时间段对应的存储容器均确定为
未失活存储容器。在此基础上，当任一边缘管理平台接收到心跳信息时，可以确定出接收到
该心跳信息时所处的单位时间段，并将发送该心跳信息的已注册终端的设备标识更新至该
单位时间段所对应的存储容器中。

[0054] 应当理解的是，本说明书通过将多个存储容器与多个单位时间段对应的方式，使得本说明书可以在无需记录接收到心跳信息的时刻的前提下，大致确定接收到各个已注册
终端发送的心跳信息时所处的单位时间段。

[0055] 在本说明书中，边缘管理平台构建的保活状态队列可以为环形队列，相应的，可以将环形队列包含的任一单位时间段对应的存储容器作为上述失活存储容器，将其他单位时
间段对应的存储容器作为上述未失活存储容器。其中，边缘管理平台还可以构建对应于该
环形队列的指针，该指针用于指示当前所处单位时间段，具体的，该指针在任一周期内，可
以由上述任一单位时间段开始，按照预设顺序依次指向下一单位时间段。在此基础上，当任
一边缘处理平台接收到心跳信息时，即可确定出指针当前所指的单位时间段，以将接收到
的心跳信息所对应的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容
器中。

[0056] 在实际应用中，还可以构建一位置存储表，以用于记录各个已注册终端的设备标识所处的存储容器。那么，本说明书即可基于该位置存储表，执行上述更新设备标识的存储
位置的操作。例如，在接收到任一已注册终端发送的心跳信息的情况下，可以根据构建的位
置存储表查询存储有该任一已注册终端的设备标识的存储容器，一方面，可以从查询到的
存储容器中删除该任一已注册终端的设备标识，另一方面，可以将该任一已注册终端的设
备标识添加至指针当前所指的存储容器，进而实现设备标识的存储位置更新。

[0057] 在本说明书中，每一边缘管理平台还可以进一步统计所辖域内各个已注册终端发送心跳信息的次数，以及各个已注册终端各自发送的若干心跳信息所述单位时间段的分布
情况，进而根据统计得到的发送次数和分布情况确定出各个已注册终端的健康度。举例而
言，假设预设周期为60分钟，每一分钟为1个单位时间段，且Dev11在上一周期中向Edge1发
送了5次心跳信息，而这5次心跳信息分别在第5、10、30、55分钟接收到，那么，Edge1即可根
据发送次数“5次”，以及这5次分布于第5、10、30、55分钟这一分布情况，确定出Dev11的健康
度。具体如何根据发送次数，以及分布情况确定该健康度，可以由本领域技术人员根据实际
情况确定，例如，若Dev11在常规状态下应当按照1分钟为时间间隔发送心跳信息，那么，
Edge1应当在一个周期内收到60次来自Dev11的心跳信息，且60次心跳信息的分布情况为每
一个时间单位各存在一次，然而，Edge1实际确定的发送次数为5次，以及这5次分布于第5、
10、30、55分钟，在该情况下，即可将该实际发送次数与常规发送次数比较、将实际分布情况
与常规分布情况进行比较，以根据两个比较结果确定Dev11的保活状态的健康度。

[0058] 在本说明书中，边缘管理平台在对任一周期内更新得到的保活状态进行聚合后，还可以对所有已注册终端的设备标识的存储位置进行初始化，以避免上一周期的保活状态
更新结果影响下一周期的保活状态更新操作。具体的，任一边缘管理平台在生成上一周期
的域内聚合结果之后，可以将存储于未失活存储容器中的设备标识更新至失活存储容器
中，进而将上一周期中除处于失活状态以外的已注册终端初始化为下一周期中的已注册终
端。

[0059] 除此之外，对于任一边缘处理平台，在每一周期中均可能接收到所辖域内的终端的注册请求。因此，该任一边缘处理平台在生成上一周期对应的域内聚合结果之后，还可以
将上一周期中请求注册的终端设备的设备标识存储至失活存储容器中，以将请求注册的终
端设备作为下一周期中新增的已注册终端。相应的，由于是新增的已注册终端，该任一边缘
处理平台还可以将新增的已注册终端的设备标识发送至云端控制中心，以由云端控制中心
对维护的全局所有已注册终端进行更新。

[0060] 进一步的，任一边缘处理平台在初始化的过程中，还可以将域内聚合结果表明的处于失活状态的已注册终端注销，以避免处于失活状态的已注册终端影响下一周期的保活
状态更新操作，具体的，可以将处于失活状态的已注册终端的标识信息从所有存储容器中
删除，以实现注销。相应的，该任一边缘处理平台还可以将注销的已注册终端的设备标识发
送至云端控制中心，以由云端控制中心对维护的全局所有已注册终端进行更新，具体的，也
可以如边缘处理平台将注销的已注册终端的设备标识删除，以实现注销。

[0061] 需要声明的是，本说明书通常将已注册终端在常规状态下发送心跳信息的时间间隔作为上述单位时间段，而预设周期所包含的单位时间段的数量则与边缘管理平台对所辖
域内的已注册终端的容忍度一致。例如，若Edge1对Dev11的容忍度为10，而Dev11在常规状
态下发送心跳信息的时间间隔为1分钟，那么，该预设周期即为10分钟。当然，该举例仅是示
意性的，具体如何设置单位时间段和预设周期，可以由本领域技术人员根据实际情况设置。

[0062] 由上述技术方案可知，本说明书在云端控制中心和已注册终端之间引入了包含多个边缘管理平台的中间层，以由各个边缘管理平台接收所辖域内的各个已注册终端发送的
心跳信息，并根据接收到的心跳信息对相应的已注册终端的保活状态进行更新。通过该方
式，使得本说明书中的云端控制中心，无需直接接收海量终端发送的心跳信息，以对多个区
域包含的海量终端的保活状态进行更新，避免了相关技术中云端控制中心负载过大的问
题。

[0063] 进一步的，本说明书中的边缘处理平台中均配置有失活存储容器和未失活存储容器。其中，在任一周期内，若边缘处理平台尚未接收到已注册终端发送的心跳信息，则相应
已注册终端的设备标识被存储于失活存储容器中，若边缘处理平台接收到了任一已注册终
端的心跳信息，则该任一已注册终端的设备标识被更新至未失活存储容器中，应当理解的
是，在任一周期内，若边缘处理平台接收到了某一已注册终端的心跳信息，则证明该已注册
终端处于未失活状态，否则，则处于失活状态。可见，本说明书通过在边缘处理平台中引入
失活存储容器和未失活存储容器的方式，使得本说明书可以在无需记录接收到心跳信息的
具体时刻、以及无需进行遍历操作的前提下，只需确定各个已注册终端的设备标识的存储
位置，即可完成对所辖域内所有已注册终端的保活状态进行更新。

[0064] 再进一步的，本说明书中的边缘管理平台还可以统计所辖域内所有已注册终端在每一周期内发送心跳信息的次数，以及各个已注册终端各自发送的若干心跳信息时所处单
位时间段的分布情况。在此基础上，即可根据统计得到的发送次数和分布情况确定出各个
已注册终端的健康度。应当理解的是，健康度反映了各个已注册终端在任一周期内发送心
跳信息的情况，能够较好地体现已注册终端发送心跳信息的过程是否保持一个较为合理的
频次，进而使得技术人员或边缘处理平台能够根据健康度反映的情况及时对心跳信息发送
异常的已注册终端进行处理。

[0065] 与上述基于云边端架构的终端保活管理系统相对应的，本说明书还提出了一种基于云边端架构的终端保活管理方法。在该方法中，仅仅是将边缘管理平台作为执行主体，对
本说明书的技术方案进行介绍，大多操作方式，例如，如何对所辖域内的已注册终端的保活
状态进行更新、如何对所辖域内所有已注册终端的保活状态进行聚合，均与上一实施例一
致，相关内容均可参照上一实施例的介绍，在下一实施例中，不再赘述。

[0066] 图2是一示例性实施例提供的一种基于云边端架构的终端保活管理方法的流程图。该云边端架构包括顶层的云端控制中心、位于中间层的多个边缘管理平台和位于底层
的已注册终端，每一边缘管理平台分别对所辖域内的已注册终端进行保活管理；该方法应
用于任一边缘管理平台，如图2所示，该方法包括：

[0067] 步骤202，接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新。

[0068] 如上所述，本说明书在云端控制中心与海量终端之间新增了包含多个边缘管理平台的中间层，其中，每一边缘管理平台对应有相应的管辖区域，以负责所辖区域内的所有已
注册终端的保活状态更新，且每一边缘处理平台可以按照预设周期对所辖域内所有已注册
终端的保活状态进行聚合，并将聚合结果上传至云端控制中心，以由云端控制中心对全局
所有已注册终端的全量保活状态进行更新。

[0069] 如上所述，每一边缘管理平台均可配置有失活存储容器和未失活存储容器。其中，对于任一边缘管理平台，在未接收到所辖域内的已注册终端的心跳信息的情况下，已注册
终端的设备标识被存储于上述失活存储容器中；而在接收到该已注册终端发送的心跳信息
的情况下，便将该已注册终端的设备标识更新至上述未失活存储容器中。在此基础上，当任
一周期结束时，该任一边缘管理平台即可确定出所辖域内所有已注册终端的设备标识的存
储位置，以根据确定出的存储位置得出上述聚合结果。

[0070] 在实际操作中，可以仅获取存储于失活存储容器中的设备标识，并将获取到的设备标识对应的已注册终端的保活状态确定为失活状态，而将除获取到的设备标识以外的其
他设备标识对应的已注册终端的保活状态确定为未失活状态；相应的，也可以仅获取存储
于未失活存储容器中的设备标识，并将获取到的设备标识对应的已注册终端的保活状态确
定为未失活状态，而将除获取到的设备标识以外的其他设备标识对应的已注册终端的保活
状态确定为失活状态。当然，在实际应用中，也可以分别获取两存储容器中保存的设备标
识，以根据从两存储容器中分别获取的设备标识确定各个已注册终端的保活状态。

[0071] 如上所述，边缘处理平台中还可以包含多个不同的未失活存储容器，并在各个未失活存储容器和不同的单位时间段之间建立映射关系，以记录接收到各个已注册终端发送
的心跳信息时所处的单位时间段。具体的，边缘管理平台可以构建包含多个单位时间段的
保活状态队列，并在多个单位时间段与多个存储容器之间建立映射关系，其中，可以将与任
一单位时间段对应的存储容器作为上述失活存储容器，而将其余单位时间段对应的存储容
器均确定为未失活存储容器。在此基础上，当任一边缘管理平台接收到心跳信息时，可以确
定出接收到该心跳信息时所处的单位时间段，并将发送该心跳信息的已注册终端的设备标
识更新至该单位时间段所对应的存储容器中。

[0072] 如上所述，边缘管理平台构建的保活状态队列可以为环形队列，相应的，可以将环形队列包含的任一单位时间段对应的存储容器作为上述失活存储容器，将其他单位时间段
对应的存储容器作为上述未失活存储容器。其中，边缘管理平台还可以构建对应于该环形
队列的指针，该指针用于指示当前所处单位时间段，具体的，该指针在任一周期内，由上述
任一单位时间段开始，按照预设顺序依次指向下一单位时间段。在此基础上，当任一边缘你
平台接收到心跳信息时，即可确定出指针当前所指的单位时间段，以将接收到的心跳信息
所对应的已注册终端的设备标识更新至确定出的单位时间段所对应的存储容器中。

[0073] 如上所述，边缘处理平台还可以构建一位置存储表，以用于记录各个已注册终端的设备标识所处的存储容器。那么，本说明书即可基于该位置存储表，执行上述更新设备标
识的存储位置的操作。例如，在接收到任一已注册终端发送的心跳信息的情况下，可以根据
构建的位置存储表查询存储有该任一已注册终端的设备标识的存储容器，一方面，可以从
查询到的存储容器中删除该任一已注册终端的设备标识，另一方面，可以将该任一已注册
终端的设备标识添加至指针当前所指的存储容器，进而实现设备标识的存储位置更新。

[0074] 步骤204，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理平台
分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0075] 如上所述，边缘管理平台在对任一周期内更新得到的保活状态进行聚合后，还可以对所有已注册终端的设备标识的存储位置进行初始化，以避免上一周期的保活状态更新
结果影响下一周期的保活状态更新操作。具体的，任一边缘管理平台在生成上一周期的域
内聚合结果之后，可以将存储于未失活存储容器中的设备标识更新至失活存储容器中，进
而将上一周期中除处于失活状态以外的已注册终端初始化为下一周期中的已注册终端。

[0076] 如上所述，对于任一边缘处理平台，在每一周期中均可能接收到所辖域内的终端的注册请求。因此，该任一边缘处理平台在生成上一周期对应的域内聚合结果之后，还可以
将上一周期中请求注册的终端设备的设备标识存储至失活存储容器中，以将请求注册的终
端设备作为下一周期中新增的已注册终端。相应的，由于是新增的已注册终端，该任一边缘
处理平台还可以将新增的已注册终端的设备标识发送至云端控制中心，以由云端控制中心
对维护的全局所有已注册终端进行更新。

[0077] 如上所述，任一边缘处理平台在初始化的过程中，还可以将域内聚合结果表明的处于失活状态的已注册终端注销，以避免处于失活状态的已注册终端影响下一周期的保活
状态更新操作，具体的，可以将处于失活状态的已注册终端的标识信息从所有存储容器中
删除，以实现注销。相应的，该任一边缘处理平台还可以将注销的已注册终端的设备标识发
送至云端控制中心，以由云端控制中心对维护的全局所有已注册终端进行更新，具体的，也
可以如边缘处理平台将注销的已注册终端的设备标识删除，以实现注销。

[0078] 由上述技术方案可知，本说明书在云端控制中心和已注册终端之间引入了包含多个边缘管理平台的中间层，以由各个边缘管理平台接收所辖域内的各个已注册终端发送的
心跳信息，并根据接收到的心跳信息对相应的已注册终端的保活状态进行更新。通过该方
式，使得本说明书中的云端控制中心，无需直接接收海量终端发送的心跳信息，以对多个区
域包含的海量终端的保活状态进行更新，避免了相关技术中云端控制中心负载过大的问
题。

[0079] 除此之外，本说明书中的边缘处理平台中均配置有失活存储容器和未失活存储容器。其中，在任一周期内，若边缘处理平台尚未接收到已注册终端发送的心跳信息，则相应
已注册终端的设备标识被存储于失活存储容器中，若边缘处理平台接收到了任一已注册终
端的心跳信息，则该任一已注册终端的设备标识被更新至未失活存储容器中，应当理解的
是，在任一周期内，若边缘处理平台接收到了某一已注册终端的心跳信息，则证明该已注册
终端处于未失活状态，否则，则处于失活状态。可见，本说明书通过在边缘处理平台中引入
失活存储容器和未失活存储容器的方式，使得本说明书可以在无需记录接收到心跳信息的
具体时刻、以及无需进行遍历操作的前提下，只需确定各个已注册终端的设备标识的存储
位置，即可完成对所辖域内所有已注册终端的保活状态进行更新。

[0080] 下面，以图1所示的Edge1在某一周期内，对所辖域内的Dev11、Dev12…等已注册终端的保活状态进行更新为例进行介绍。

[0081] 图3是一示例性实施例提供的一种基于云边端架构的终端保活管理方法的交互图。如图3所示，该方法包括以下步骤：

[0082] 步骤301，各个已注册终端向Edge1发送心跳信息。

[0083] 在本实施例中，位于各个区域的终端可以通过向所属区域对应的边缘管理平台发送注册请求的方式，将设备信息注册至相应的边缘管理平台。在此基础上，各个边缘管理平
台即可对注册至本地的所辖域内的已注册终端的保活状态进行维护。

[0084] 举例而言，假设总共存在“第一区域”、“第二区域”、“第三区域”3个区域，且为这3个区域分别配置的边缘管理平台为如图1所示的Edge1、Edge2和Edge3。那么，属于第1区域
的Dev11、Dev12和Dev13即可向Edge1发送注册请求，以注册成为Edge1对应的已注册终端。
在完成注册之后，Dev11、Dev12和Dev13的设备标识均被存储于失活存储容器中。此时，
Edge1中所有已注册终端的设备标识的存储位置可以如表1所示：

[0085]失活存储容器 未失活存储容器
Dev11、Dev12、Dev13  

[0086] 表1

[0087] 在完成注册之后，Dec11、Dev12和Dec13即可通过向Edge1发送心跳信息的方式，使Edge1对相应的已注册终端的设备标识的存储位置进行更新，进而实现保活状态的更新。

[0088] 步骤302，Edge1根据接收到的心跳信息，对相应的已注册终端的保活状态进行更新。

[0089] 承接上述举例，若在本周期的某一时刻接收到了Dev11发送的心跳信息，则可以将Dev11的设备标识更新至未失活存储容器中，而Dev12和Dev13的设备标识则保持于原来的
存储位置。

[0090] 步骤303，Edge1在本周期结束时，对所有已注册终端的保活状态进行聚合。

[0091] 承接上述举例，假设在本周期内，仅接收到了Dev11和Dev12的心跳信息，那么，仅Dev11和Dev12的设备标识被更新至未失活存储容器中，而Dev13的设备标识则仍位于失活
存储容器中。具体的，本周期结束时，所有已注册终端的设备标识的存储位置可以如表2所
示：

[0092] 失活存储容器 未失活存储容器Dev13 Dev11、Dev12

[0093] 表2

[0094] 步骤304，Edge1将聚合结果发送至云端控制中心。

[0095] 承接上述举例，Edge1即可将表2所示的信息发送至云端控制中心（即图3中的Cloud Control Center），以由云端控制中心对维护的Dev13的保活状态标记为失活状态，
而Dev11和Dev12的保活状态标记为未失活状态。

[0096] 步骤305，云端控制中心根据接收到的聚合结果，对维护的全局所有已注册终端的保活状态进行更新。

[0097] 由上述技术方案可知，本实施例可以在云端控制中心和底层终端之间引入包含多个边缘处理平台中间层，以通过各个边缘处理平台对所辖域内的已注册终端的保活状态进
行更新。应该理解的是，由于已注册终端发送的心跳信息由边缘处理平台进行接收并处理，
避免了相关技术中由于需要云端控制中心直接接收各个区域的海量终端发送的心跳信息，
并对其进行处理，而造成的云端控制中心负载过高的问题。

[0098] 进一步的，本实施例中的边缘处理平台配置有失活存储容器和未失活存储容器，其中，在任一周期内，未接收到心跳信息的已注册终端的设备标识始终被存储于失活存储
容器中，接收到的心跳信息所对应的已注册终端的设备标识被更新至未失活存储容器中。
通过该方式，使得本实施例只需确定出各个已注册终端的设备标识的存储位置，即可对已
注册终端的保活状态进行更新，避免了相关技术中需要对所有已注册终端发送心跳信息的
时刻进行遍历，而造成的更新效率低下的问题。

[0099] 下面，以Edge1在接收到Dev11发送的心跳信息时，通过环形队列对Dev11的保活状态进行更新为例，介绍本说明书的保活状态更新方法。

[0100] 图4是一示例性实施例提供的一种应用于边缘管理平台的保活状态更新方法的流程图。如图4所示，该方法包括以下步骤：

[0101] 步骤401，接收到Dev11发送的心跳信息。

[0102] 在本实施例中，Edge1在开始维护所辖领域内的所有已注册终端的保活状态之前，需要进行一定的准备工作。首先，Edge1可以构建包含多个单位时间段的环形队列，以及对
应于该环形队列的指针和位置存储表，并在环形队列包含的各个单位时间段与多个存储容
器之间建立映射关系。

[0103] 举例而言，可以构建如图5所示的包含8个单位时间段的环形队列51，以及对应于该环形队列51的指针52、位置存储表53。在此基础上，即可在环形队列51包含的单位时间段
0 7与图5中所示的多个存储容器54之间建立映射关系，具体的，单位时间段0与存储容器0’
~
对应、单位时间段1与存储容器1’对应，以此类推。

[0104] Edge1在构建上述各个对象之后，可以将单位时间段0所对应的存储容器0’作为失活存储容器、将存储容器1’7’作为未失活存储容器，并将所辖域内的所有已注册终端的设
~
备标识存储于存储容器0’中，以及在位置存储表中记录所有已注册终端的设备标识的存储
位置，假设Edge1所辖域内仅包含Dev11、Dev12和Dev13，此时，位置存储表中的记录情况可
以如下表3所示：

[0105] 存储容器 设备标识0’ Dev11、Dev12、Dev13
1’  
2’  
3’  
4’  
5’  
6’  
7’  

[0106] 表3

[0107] 由表3可知，在尚未接收到任何心跳信息之前，所有已注册终端的设备标识被存储于作为失活存储容器的存储容器0’中，相应的，指针52此时指向单位时间段0。而在进入任
一周期后，指针便按照“0、1、2、3……7”的顺序依次指向下一个单位时间段。

[0108] 步骤402，在位置存储表中查询Dev11的设备标识所处的存储容器。

[0109] 承接上述举例，假设每一个单位时间段的时长为1分钟，且在进入某一周期后经过了2分54秒时，Edge1接收到了Dev11发送的心跳信息。此时，Edge1即可从位置存储表中查询
得到Dev11的设备标识当前存储于存储容器0’中，且指针52当前所指的单位时间段为单位
时间段2。那么，Edge1可以将存储于存储容器0’中的Dev11的设备标识删除，并将Dev11的设
备标识存储至存储容器2’中。相应的，Edge1将位置存储表中的记录更新为如表4所示：

[0110]存储容器 设备标识
0’ Dev12、Dev13
1’  
2’ Dev11
3’  
4’  
5’  
6’  
7’  

[0111] 表4

[0112] 步骤403，在查询到的存储容器中删除Dev11的设备标识。

[0113] 步骤404，确定指针当前所指的单位时间段。

[0114] 步骤405，将Dev11的设备标识存储至确定的单位时间段对应的存储容器中。

[0115] 应当理解的是，Edge1在接收到所辖域内的其他已注册终端发送的心跳信息时，对其保活状态进行更新的操作也是类似，可参照上述针对Dev11的介绍，在此不再赘述。

[0116] 由上述技术方案可知，本实施例通过构建环形队列，以及对应于该环形队列的位置存储表和指针的方式，使得边缘处理平台在接收到所辖域内任一已注册终端发送的心跳
信息时，通过变更设备标识的存储位置的方式对已注册终端的保活状态进行更新。

[0117] 下面，以Edge1在任一周期结束后，对所辖域内的所有已注册终端的保活状态进行聚合的过程进行介绍。

[0118] 图6是一示例性实施例提供的一种应用于边缘管理平台的保活状态聚合方法的流程图。如图6所示，该方法包括以下步骤：

[0119] 步骤601，获取存储于失活存储容器中的设备标识。

[0120] 承接上一实施例的举例，Edge1可以在上一实施例所处的周期结束时，根据各个存储容器中存储的设备标识，确定出相应的已注册终端的保活状态。假设在上一实施例所处
的周期内，Edge1还在5分12秒接收到了Dev12发送的心跳信息，而未接收到Dev13发送的心
跳信息，那么，在该周期结束时，位置存储表中的记录情况如下表5所示：

[0121]存储容器 设备标识
0’ Dev13
1’  
2’ Dev11
3’  
4’  
5’ Dev12
6’  
7’  

[0122] 表5

[0123] 步骤602，将获取到的设备标识作为聚合结果上传至云端控制中心。

[0124] 在本实施例中，仅将处于失活状态的设备标识作为聚合结果，上传至云端控制中心，而将其他设备标识对应的已注册终端的保活状态默认为未失活状态。

[0125] 承接上述举例，可以仅将Dev13的设备标识作为聚合结果，上传至云端控制中心。而云端控制中心，则可以将Dev13的保活状态确定为失活状态，而将Dev11和Dev12的保活状
态默认为未失活状态。

[0126] 步骤603，获取存储于未失活存储容器中的设备标识。

[0127] 步骤604，将获取到的设备标识存储至失活存储容器中。

[0128] 为了避免上一周期的保活状态更新结果影响下一周期的保活状态更新操作，本实施例还可以对已注册终端的设备标识进行初始化。

[0129] 承接上述举例，可以将存储于存储容器2’中的Dev11的设备标识删除，并将该设备标识存储至存储容器0’中；将存储于存储容器5’中的Dev11的设备标识删除，并将该设备标
识也存储至存储容器0’中。在完成该操作后，位置存储表中的记录情况可以如表6所示：

[0130] 存储容器 设备标识0’ Dev11、Dev12
1’  
2’  
3’  
4’  
5’  
6’  
7’  

[0131] 表6

[0132] 步骤605，获取上一周期中请求注册的终端的设备标识。

[0133] 承接上述举例，假设上一周期中，Edge1还接收到了所辖域内的Dev14和Dev15发送的注册请求，那么，在初始化的过程中，Edge1还可以将Dev14和Dev15的设备标识也存储至
存储容器0’中，以作为下一周期中的已注册终端。此时，位置存储表中的记录情况可以如表
7所示：

[0134]存储容器 设备标识
0’ Dev11、Dev12、Dev14、Dev15
1’  
2’  
3’  
4’  
5’  
6’  
7’  

[0135] 表7

[0136] 步骤606，将获取到的设备标识存储至失活存储容器中。

[0137] 需要声明的是，尽管在本实施例的介绍中，将初始化过程划分为多个步骤，但在实际操作中，上述步骤603与604、步骤605 606可以并行执行。
~

[0138] 由上述技术方案可知，本说明书中的边缘管理平台可以根据各个已注册终端的设备标识的存储位置，确定出各个已注册终端的保活状态，进而避免了相关技术中需要记录
接收到各个已注册终端发送的心跳信息的时刻的情况，以及在需要进行遍历才能实现保活
状态更新的问题，提高了保活状态更新操作的执行效率。

[0139] 进一步的，本实施例中的边缘处理平台在完成聚合操作之后，还可以对设备标识的存储位置进行初始化。具体的，一方面，可以将确定为未失活状态的已注册终端的设备标
识存储至失活存储容器中；另一方面，可以将上一周期中请求注册的终端的设备标识存储
至失活存储容器中。通过该方式，本实施例避免了上一周期的保活状态更新结果，对下一周
期的保活状态更新结果造成影响的问题。

[0140] 图7是一示例性实施例提供的一种设备的示意结构图。请参考图7，在硬件层面，该设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器710，当然还
可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，
比如由处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行。
当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻
辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻
辑单元，也可以是硬件或逻辑器件。

[0141] 请参考图8，基于云边端架构的终端保活管理装置可以应用于如图7所示的设备中，以实现本说明书的技术方案。其中，该基于云边端架构的终端保活管理装置可以包括：

[0142] 更新单元801，接收所辖域内的已注册终端发送的心跳信息，并根据所述心跳信息对相应的已注册终端的保活状态进行更新；

[0143] 聚合单元802，按照预设周期对所辖域内的所有已注册终端的保活状态进行聚合，并将生成的域内聚合结果上传至云端控制中心，以由所述云端控制中心根据各个边缘管理
平台分别上传的域内聚合结果对全局所有已注册终端的保活状态进行维护。

[0144] 可选的，更新单元801被进一步用于：

[0145] 将发送所述心跳信息的已注册终端的设备标识更新至未失活存储容器中；其中，在接收到任一已注册设备发送的心跳信息之前，所述任一已注册终端的设备标识被所述任
一边缘管理平台存储于失活存储容器中；

[0146] 聚合单元802被进一步用于：

[0147] 获取存储于所述失活存储容器中的设备标识，以将获取到的设备标识所对应的已注册终端的保活状态确定为失活状态；和/或，获取存储于所述未失活存储容器中的设备标
识，以将获取到的设备标识对应的已注册终端的保活状态确定为未失活状态。

[0148] 可选的，还包括：

[0149] 构建单元803，构建包含多个单位时间段的保活状态队列，并将与任一单位时间段对应的存储容器作为所述失活存储容器、将区别于所述任一单位时间段的其他单位时间段
所对应的存储容器确定为未失活存储容器；

[0150] 更新单元801被进一步用于：确定出接收到所述心跳信息时所处的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所对应的存储
容器中。

[0151] 可选的，所述保活状态队列为环形队列；

[0152] 构建单元803被进一步用于：生成对应于所述环形队列的指针，所述指针在每一周期内，从所述任一单位时间段开始按照预设顺序依次指向下一个单位时间段；

[0153] 更新单元801被进一步用于：当接收到所述心跳信息时，确定出所述指针所指的单位时间段，并将发送所述心跳信息的已注册终端的设备标识更新至确定出的单位时间段所
对应的存储容器中。

[0154] 可选的，

[0155] 构建单元803被进一步用于：构建位置存储表，所述位置存储表记录有各个已注册终端的设备标识所处的存储容器；

[0156] 更新单元801被进一步用于：在接收到任一已注册终端发送的心跳信息的情况下，根据所述位置存储表确定出存储有所述任一已注册终端的设备标识的存储容器，并将存储
于确定出的存储容器中的所述任一已注册终端的设备标识删除、在所述指针当前所指的存
储容器中添加所述任一已注册终端的设备标识。

[0157] 可选的，还包括：

[0158] 统计单元804，统计所辖域内各个已注册终端发送心跳信息的次数、以及所述各个已注册终端各自发送的若干心跳信息所处单位时间段的分布情况，以根据统计得到的发送
次数和分布情况确定出各个已注册终端的健康度。

[0159] 可选的，还包括：

[0160] 初始化单元805，在生成所述域内聚合结果之后，将上一周期中请求注册的终端设备的设备标识存储至所述失活存储容器中，以将所述终端设备作为下一周期中新增的已注
册终端；以及，将新增的已注册终端的设备标识发送至所述云端控制中心，以使所述云端控
制中心对维护的全局所有已注册终端进行更新。

[0161] 可选的，还包括：

[0162] 注销单元806，在生成所述域内聚合结果之后，注销处于失活状态的已注册终端；以及，将注销的已注册终端的设备标识发送至所述云端控制中心，以使所述云端控制中心
对维护的全局所有已注册终端进行更新。

[0163] 上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可
以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放
器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的
任意几种设备的组合。

[0164] 在一个典型的配置中，计算机包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。

[0165] 内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介
质的示例。

[0166] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。
计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、
动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电
可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 
(CD‑ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、
基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计
算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 
(transitory media)，如调制的数据信号和载波。

[0167] 还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包
括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要
素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要
素的过程、方法、商品或者设备中还存在另外的相同要素。

[0168] 上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来
执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺
序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可
以的或者可能是有利的。

[0169] 在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书
中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表
示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出
项目的任何或所有可能组合。

[0170] 应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区
分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第
二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如
果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

[0171] 以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何
修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。