CN110798349B

CN110798349B - 一种配置分发、接收方法、设备及计算机可读存储介质

Info

Publication number: CN110798349B
Application number: CN201911029378.3A
Authority: CN
Inventors: 邹学强; 刘洋; 蒋军; 黄德健; 袁庆升; 王小华
Original assignee: National Computer Network and Information Security Management Center
Current assignee: National Computer Network and Information Security Management Center
Priority date: 2019-10-28
Filing date: 2019-10-28
Publication date: 2023-02-28
Anticipated expiration: 2039-10-28
Also published as: CN110798349A

Abstract

本发明公开了一种配置分发、接收方法、设备及计算机可读存储介质，所述分发方法包括如下步骤：建立与接收设备之间的心跳连接，在系统收到配置数据后，根据配置订阅列表按照配置消息格式向接收设备分发配置数据；获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态。本发明实施例通过根据配置订阅列表按照配置消息格式向接收设备分发配置数据，并根据反馈信息更新本次配置分发节点的状态，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题，同时也不影响业务系统之间的独立性。

Description

一种配置分发、接收方法、设备及计算机可读存储介质

技术领域

本发明涉及业务系统技术领域，尤其涉及一种配置分发、接收方法、设备及计算机可读存储介质。

背景技术

在大型分布式业务系统中，通常存在多种不同的业务子系统或者数据处理子系统，子系统正常运行期间都需要接收总控管理界面下发的业务配置数据，由于每种业务系统功能不同、覆盖用户不同、设备规模不同，因此需要独立的数据分发系统来完成分发工作。现有方式中采用直接C/S模式不仅分发效率低下，而且不能够保证数据最终的一致性；采用大数据集群模式则不符合业务独立需求。

现有的技术方案存在如下技术问题：

直接C/S方式，B和S之间彼此只完成数据发送成确认，B并不在知道S中的节点是否全部收到了完整的数据；

直接C/S方式，对物理设备依赖性强，当物理设备增加或者减少时，数据分发系统软件需要升级、重新配置，导致系统的扩展性和伸缩性变差；

发明内容

本发明实施例提供一种配置分发、接收方法、设备及计算机可读存储介质，用以解决现有技术中存在的分发设备与接收设备之间无法业务确认及数据一致性差问题。

第一方面，本发明实施例提供一种配置分发方法，所述分发方法包括如下步骤：

建立与接收设备之间的心跳连接，在系统收到配置数据后，根据配置订阅列表按照配置消息格式向接收设备分发配置数据；

获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态。

可选的，建立与接收设备之间的心跳连接，还包括：

在系统加入新的节点的情况下，建立与新加入节点的心跳连接，并将新加入节点补入配置订阅列表；

在分发侧设备在指定时间内未收到新加入节点的心跳消息的情况下，将新加入节点从所述配置订阅列表中删除。

可选的，所述配置消息格式包括配置条目、配置跟踪ID和配置ID；

所述配置跟踪ID具有唯一性，且每个配置ID对应于一个配置跟踪ID。

可选的，根据所述反馈信息更新本次配置分发节点的状态，包括：

根据所述反馈信息更新本次配置分发所有节点的状态；

在分发失败的情况下，将分发失败的节点加入重发队列；

保持配置跟踪ID，基于所述重发队列进行重复配置分发。

第二方面，本发明实施例提供一种配置接收方法，所述接收方法包括如下步骤，

建立与分发设备的心跳连接，并向分发设备发送配置消息订阅请求；

接收所述分发设备按照配置消息格式分发的配置数据；

根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息。

可选的，所述配置消息订阅请求，包括：配置分发模式；

所述配置消息格式包括：配置条目、配置跟踪ID和配置ID，所述配置跟踪ID具有唯一性，且每个配置ID对应于一个配置跟踪ID。

可选的，根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息，包括：

在所接收到的配置条目与指示的配置条目总量不一致的情况下，将接收到的配置消息格式反馈给分发设备，并等待重新接收；

在任意接收节点设备重新启动或软件升级更新后，向分发设备发送全量配置请求，所述全量配置请求中的配置跟踪ID与重新启动前或软件升级更新前保持不变。

第三方面，本发明实施例提供一种配置分发设备，所述分发设备包括：

第一通信单元，用于建立与接收设备之间的心跳连接；

配置发送单元，用于在系统收到配置数据后，根据配置订阅列表按照配置消息格式向接收设备分发配置数据；

状态更新单元，用于获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态。

第四方面，本发明实施例提供一种配置接收设备，所述接收设备包括：

第二通信单元，用于建立与分发设备的心跳连接，并向分发设备发送配置消息订阅请求；

配置接收单元，用于接收所述分发设备按照配置消息格式分发的配置数据；

状态反馈单元，用于根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息。

第五方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现第一实施例或第二实施例的方法的步骤。

本发明实施例通过根据配置订阅列表按照配置消息格式向接收设备分发配置数据，获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题，同时也不影响业务系统之间的独立性，取得了积极的技术效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为现有的数据分发模型；

图2为本发明第一实施例流程图；

图3为本发明第一实施例消息机制示意图；

图4为本发明第一实施例配置订阅列表结构示意图；

图5为本发明第一实施例消息结构示意图；

图6为本发明第一实施例跟踪ID和配置ID映射表；

图7为本发明第一实施例配置推送示意图；

图8为本发明第二实施例配置拉取示意图；

图9为本发明第二实施例请求消息结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在大型分布式业务系统中，通常存在多种不同的业务子系统或者数据处理子系统，子系统正常运行期间都需要接收总控管理界面下发的业务配置数据，由于每种业务系统功能不同、覆盖用户不同、设备规模不同，因此需要独立的数据分发系统来完成分发工作，如图1所示，但是由于业务需求发展或系统运行状态变化，某业务系统处理节点可能会增加，如图中情景①；

由于节点宕机，某业务系统处理节点减少，如图中情景②；

由于数据分发系统自身故障，导致某业务系统的数据分发工作需要数据分发系统中的其他节点来接管，如图中情景③。

一般情况下，数据分发群为：{B1→(S11,S12,S13)}，{B2→(S21,S22,S23)}，{B3→(S31,S32,S33)}；当出现上述①②③情景时，数据分发群变为：{B1→(S11,S12,S13,S1x)}，{B2→(S21,S23)}，{B1→(S11,S12,S13,S31,S32,S33)}/{B1→(S11,S12,S13,S31)},{B2→(S21,S22,S23,S32,S33)}/…。

随着节点规模的不断增加，出现故障的概率也在增加，{B→S}分发群数量也在不断变化，数据分发的一致性变得越来越难控制，现有的数据分发系统中{B→S}的数据分发方式存在如下技术缺陷：

采用Zookeeper集群方式，即在B，S组成一个集群，Zookeeper的内部Leader选举机制可确保S数据的一致性，但是这个不符合业务独立性需要，如图1中业务系统1、业务系统2、业务系统3、数据分发系统之间要彼此相互独立。

由此，本发明第一实施例提供一种配置分发方法，如图2所示，所述分发方法包括如下步骤：

如图3所示，本发明方法包括三个方面，其一是配置分发设备与配置接收设备之间建立心跳连接，其二是配置分发设备向配置接收设备进行配置推送，其三是配置接收设备向配置分发设备进行配置拉取，下面对上述三个方面进行具体阐述。

对于配置推送，在本实施例中，配置推送：用于实现配置分发设备B主动向配置接收设备S发送配置；当数据分发系统收到配置数据后，按照配置订阅列表，经过匹配后向S主动推动配置数据。

本发明实施例通过根据配置订阅列表按照配置消息格式向接收设备分发配置数据，获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题。

可选的，在本发明一个可选的实施例中，建立与接收设备之间的心跳连接，还包括：

具体的说，在本实施例中，建立与接收设备(节点)的心跳连接，也即心跳保活流程，包括，用户B和S之间建立连接并进行连接保持，并配置消息订阅；当业务系统加入新的节点时，该节点部署心跳连接流程，新加入节点启动时会主动向B节点心跳消息，并发出配置消息订阅请求包括配置分发模式，其中，配置分发模式包括推送方式、拉取方式或两者相互结合方式。

本实施例中的配置订阅列表的构建主要包括，如图4所示，建立并维护分发侧设备节点B与接收侧设备节点S所需配置之间的映射关系，当B接收S的配置请求时，如果是首次请求，B会将S插入配置请求列表中，其中配置跟踪ID链表为空，并将全量配置分发给S，更新配置跟踪ID列表；如果非首次请求，B获取请求消息中的配置跟踪ID，通过比对配置ID链表获取配置存储地址，读取数据发送给S，更新配置ID链表。

进一步的，在本实施例中，在分发侧设备B在指定时间内未收到新加入节点S的心跳消息的情况下，将新加入节点从所述配置订阅列表中删除，例如，10秒1次心跳消息保持连接，当超过10秒未收到心跳消息，B认为S宕机，从配置订阅列表中清除。

如图5所示，本实施例中，提出本发明方法的消息结构，其中配置消息结构包括：配置跟踪ID、配置条目、配置ID、消息体，其中，配置跟踪ID：用于识别发送的批次，即某条配置在那个批次发送过，批次ID具有唯一性；

配置条目：用于标识本次发送的配置条目总量；

配置ID：某条配置的全局唯一标识，每个配置ID只对应一个配置跟踪ID，如图6所示。

消息体：具体定义配置内容，也即分发的配置数据。

在本实施例中，配置ID和消息体采用Key-Value形式进行组织。

可选的，在本发明另一个可选的实施例中，根据所述反馈信息更新本次配置分发节点的状态，包括：

根据所述反馈信息更新本次配置分发所有节点的状态；

在分发失败的情况下，将分发失败的节点加入重发队列；

保持配置跟踪ID，基于所述重发队列进行重复配置分发。

具体的说，在进行配置推送时，配置接收设备S收到后，根据收到情况向B返回收到的配置消息格式，包括配置条目、配置跟踪ID、配置ID，如果发送失败，分发设备B将该S节点加入重发队列，并将缺失的配置数量、配置ID做一个映射。

如图7所示，无论发送成功与否，分发设备B都会更新本次配置分发所有节点的状态，将分发不成功的节点全部加入重发队列，等再次重新分发，重新分发过程中保持之前的配置跟踪ID不变，可选的，可以对整个配置分发时间进行时效性要求，例如，采用定时重发机制每15分钟重新发送1次。

基于本实施例的方法，可保证配置接收设备S彼此之间收到的配置数据在要求的时效性内是一致的，并且B和S之间彼此互不依赖，随着业务规模的不断调整，可灵活适应变化。

接收所述分发设备按照配置消息格式分发的配置数据；

在本实施例中，本发明实施例通过向分发设备发送配置消息订阅请求，接收对应的配置数据，并根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题。

对于配置推送，在本实施例中，配置推送：用于实现配置分发设备B主动向配置接收设备S发送配置；当数据分发系统收到配置数据后，按照配置订阅列表，经过匹配后向S主动推动配置数据。在进行配置推送时，配置接收设备S收到后，根据收到情况向B返回收到的配置消息格式，包括配置条目、配置跟踪ID、配置ID，如果发送失败，分发设备B将该S节点加入重发队列，并将缺失的配置数量、配置ID做一个映射。

可选的，所述配置消息订阅请求，包括：配置分发模式；

其中，配置跟踪ID：用于识别发送的批次，即某条配置在那个批次发送过，批次ID具有唯一性；

配置条目：用于标识本次发送的配置条目总量；

配置ID：某条配置的全局唯一标识，每个配置ID只对应一个配置跟踪ID。

消息体：具体定义配置内容，也即分发的配置数据。

其中，配置ID和消息体采用Key-Value形式进行组织。

在本实施例中，配置消息订阅请求中包括，配置分发模式，推送方式、拉取方式、两者相互结合方式。

在本实施例中，在分发设备B在指定时间内未收到新加入节点S的心跳消息的情况下，分发设备B会将新加入节点从所述配置订阅列表中删除，例如，10秒1次心跳消息保持连接，当超过10秒未收到心跳消息，S会被认为宕机，从而被分发设备B从订阅列表中清除。

具体的说，如图8所示，在本实施例中，配置接收设备S收到后，根据收到情况向B返回收到的配置条目、配置跟踪ID、配置ID，如果发送失败，则需要请求分发设备B进行重新发送。

进一步说，配置接收设备收到配置后，检测发现收到的配置条目总数与指示的配置总量不一致，则认为配置有丢失，这时不等配置分发设备推送，会主动将收到的配置条目和配置ID、配置跟踪ID发送给配置分发设备B，并请求立即发送缺失配置，分发设备B根据缺失配置进行重新发送。

对于配置拉取的情况，如图8所示，也即配置接收设备S主动向分发设备B获取配置，有三种情况，其一是缺失拉取，该种情况已经在前述实施例中有详细阐述。

其二是重启或系统更新或软件升级的情况，会进行全量拉取，在这种情况下，当S节点设备重新启动或者软件升级更新后，向分发设备B请求全量配置，其中配置所述的配置跟踪ID保持不变，分发过程类似于前述实施例，分发设备B收到请求后会将所有批次的配置全部发送给S，更新S节点发送状态，如果发送失败，加入重发队列。

其三是某些情况下，S需要向B请求某配置跟踪ID下的全部配置数据，B收到请求后将某配置跟踪ID映射的所有配置全部发送给S，分发过程类似于前述实施例，更新S节点发送状态，如果发送失败，加入重发队列。

在本实施例中，如图9所示，配置接收设备S向分发设备B发送的配置请求的消息结构，包括魔数、请求类型、预留、配置跟踪ID、配置条目、配置ID等构件，分发设备B可以根据请求消息的内容来完成配置的分发。

本发明的技术方案基于消息订阅模式，设计了一套数据分发系统和分布式业务子系统之间配置分发方案，通过专有的消息格式和接口流程，代理原有的C/S处理方式，有效解决了数据一致性问题，同时该装置不会对配置分发设备B和配置接收设备S形成依赖，具有良好的系统扩展性和伸缩性。

第一通信单元，用于建立与接收设备之间的心跳连接；

本发明实施例的设备通过根据配置订阅列表按照配置消息格式向接收设备分发配置数据，并获取接收设备根据所述配置消息格式返回的反馈信息，根据所述反馈信息更新本次配置分发节点的状态，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题。

本发明实施例通过向分发设备发送配置消息订阅请求，接收对应的配置数据，并根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息，由此解决了现有技术存在的分发设备与接收设备之间无法业务确认及数据一致性差问题。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims

1.一种配置接收方法，其特征在于，所述接收方法包括如下步骤，

接收所述分发设备按照配置消息格式分发的配置数据；

根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息；

其中，配置消息结构包括：配置条目、配置跟踪ID、配置ID和消息体，所述配置跟踪ID具有唯一性，且每个配置ID对应于一个配置跟踪ID；

根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息，包括：

在所接收到的配置条目与指示的配置条目总量不一致的情况下，将收到的配置条目和配置ID、配置跟踪ID发送给所述分发设备，请求发送缺失配置，并等待重新接收；

2.一种配置接收设备，其特征在于，所述接收设备包括：

状态反馈单元，用于根据配置数据的接收情况，基于所述配置消息格式向所述分发设备返回反馈信息；

所述状态反馈单元具体用于：

3.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现如权利要求1所述的方法的步骤。