CN115185705A

CN115185705A - 一种消息通知方法、装置、介质及设备

Info

Publication number: CN115185705A
Application number: CN202110368222.9A
Authority: CN
Inventors: 易龙; 孟岸
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-04-06
Filing date: 2021-04-06
Publication date: 2022-10-14

Abstract

本申请公开了消息通知方法、装置、介质及设备，涉及数据通信领域，该方法包括：获取通知任务的任务消息，将任务消息发往分布式消息队列；分布式消息队列包括对应多个消息主题的多个消息队列；确定订阅的消息主题，从与订阅的消息主题对应的消息队列中获取目标任务消息；根据目标任务消息中的第一标识数据，从注册中心获取与第一标识数据对应的目标注册信息；根据目标注册信息确定目标任务消息的目的接口地址；向与目的接口地址对应的目标业务服务发送目标任务消息。本申请提供的方案能保证消息通知的及时和可管控，提升服务器运营的效率。

Description

一种消息通知方法、装置、介质及设备

技术领域

本申请涉及数据通信领域，具体涉及一种消息通知方法、装置、介质及设备。

背景技术

随着云业务的发展，为保证用户业务运行的稳定性和持续性，对服务器运营提出了更高的要求，特别是与数据计算相关的业务场景需求。在服务器数据运营领域，数据量大且数据应用场景多样，频繁地涉及到数据调度系统和业务系统的交互，主要是需要在调度系统中的某个任务节点完成后通知业务系统以触发其执行某个业务服务。

数据调度系统和业务系统之间的消息通知机制存在缺点，例如：服务器数据计算模型的调度任务通知外部系统的实现方案较为复杂，容易产生耦合；调度系统外部通知机制不支持消息失败重试等。因此，有必要对服务器运营领域中的消息通知机制作出改善。

发明内容

为了提高消息通知的效率和可管控性，本申请提供了一种消息通知方法、装置、介质及设备。所述技术方案如下：

第一方面，本申请提供了一种消息通知方法，所述方法包括：

获取至少一个通知任务的任务消息，将所述任务消息发往分布式消息队列；所述分布式消息队列包括对应多个消息主题的多个消息队列；

确定订阅的消息主题，从与所述订阅的消息主题对应的消息队列中获取目标任务消息；

根据所述目标任务消息中的第一标识数据，从注册中心获取与所述第一标识数据对应的目标注册信息，所述目标注册信息基于所述注册中心的注册页面生成；

根据所述目标注册信息确定所述目标任务消息的目的接口地址；

向与所述目的接口地址对应的目标业务服务发送所述目标任务消息。

第二方面，本申请提供了一种消息通知装置，所述装置包括：

获取发送模块，用于获取至少一个通知任务的任务消息，将所述任务消息发往分布式消息队列；所述分布式消息队列包括对应多个消息主题的多个消息队列；

第二获取模块，用于确定订阅的消息主题，从与所述订阅的消息主题对应的消息队列中获取目标任务消息；

第三获取模块，用于根据所述目标任务消息中的第一标识数据，从注册中心获取与所述第一标识数据对应的目标注册信息，所述目标注册信息基于所述注册中心的注册页面生成；

地址确定模块，用于根据所述目标注册信息确定所述目标任务消息的目的接口地址；

消息发送模块，用于向与所述目的接口地址对应的目标业务服务发送所述目标任务消息。

第三方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如第一方面所述的一种消息通知方法。

第四方面，本申请提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由所述处理器加载并执行以实现如第一方面所述的一种消息通知方法。

第五方面，本发明提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如第一方面所述的一种消息通知方法。

本申请提供的一种消息通知方法、装置、设备及存储介质，具有如下技术效果：

本申请提供的方案引入分布式消息队列，发布者的消息根据消息主题分开存储，订阅者只需订阅消息的主题即可消费数据而不必关心数据的物理地址，可以解决任务调度和消息通知、任务调度与业务服务的功能耦合的问题；本申请提供的方案可以通过消息重试和告警措施，提高消息的发送成功率，提升消息通知的可靠性；本申请提供的方案通过设置注册中心提供可视化的动态配置和管控，提升服务器运营的处理效率。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本申请实施例提供的一种消息通知方法的实施环境示意图；

图2是本申请实施例提供的一种消息通知方法的流程示意图；

图3(1)和图3(2)是本申请实施例提供的数据调度系统中任务视图的示意图；

图4是本申请实施例提供的一个主题的分区日志的示意图；

图5是本申请实施例提供的一个区块链系统的结构示意图；

图6是本申请实施例提供的一种获取与所述第一标识数据对应的目标注册信息的流程示意图；

图7是本申请实施例提供的一种根据所述未能成功发送的原因类型进行重试或告警的流程示意图；

图8是本申请实施例提供的一种将未能成功发送的消息进行重试的流程示意图；

图9是本申请实施例提供的一种基于定时任务的消息通知方法示意图；

图10是本申请实施例提供的一种基于kafka消息队列的消息通知方法的流程示意图；

图11是本申请实施例提供的一种消息通知装置的示意图。

图12是本申请实施例提供的用于实现一种方法的设备的硬件结构示意图。

具体实施方式

本申请实施例提供了一种消息通知方法、装置、介质及设备。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于理解本申请实施例所述的技术方案及其产生的技术效果，本申请实施例对于涉及到的相关专业名词进行解释：

Kafka：是一个分布式、分区的、多副本的、多订阅者，基于Zookeeper协调的分布式日志系统(也可以当做消息中间件系统)，常见可以用于Web/Nginx日志、访问日志，消息服务等等。

消息系统：一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。在发布-订阅消息系统中，消息被持久化到一个Topic(主题)中。与点对点消息系统不同的是，消费者可以订阅一个或多个Topic，消费者可以消费该Topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者(Producer)称为发布者，消费者(Consumer)称为订阅者。

Broker：Kafka集群包含一个或多个服务器，服务器节点称为broker。broker存储Topic的数据。

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处。Topic在逻辑上可以被认为是一个queue(队列)，每条消费都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。

Partition：分区；Topic中的数据分割为一个或多个partition。每个Topic至少有一个partition。每个partition中的数据使用多个segment(分段)文件存储。segment文件包括以log结尾的数据文件和以index结尾的为索引文件。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

Producer：生产者即数据的发布者，该角色将消息发布到Kafka的Topic中。生产者在发送消息时必须指定发往哪个Topic，此后，订阅了该Topic的所有消费者都能够接收到消息。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

Consumer：消费者可以从broker中读取数据，消费者可以消费多个Topic中的数据。

耦合：是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。

Redis：Remote Dictionary Server，远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value(键值对)数据库，并提供多种语言的应用程序接口。

离线计算：通常也称为“批处理”，表示那些离线批量、延时较高的静态数据处理过程。离线计算适用于实时性要求不高的场景，比如离线报表、数据分析等，延时一般在分钟级或小时级，多数场景是定时周期性执行一个Job任务，任务周期可以小到分钟级，比如每五分钟做一次统计分析，大到月级别、年级别，比如每月执行一次任务。熟悉的MapReduce就是一个离线计算框架，Spark SQL也通常用于离线计算任务。

请参阅图1，其为本申请实施例提供的一种消息通知方法的实施环境示意图，如图1所示，该实施环境可以至少包括客户端01、服务器02和服务器03。

具体的，所述客户端01可以包括智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备、监控设备及语音交互设备等类型的设备，也可以包括运行于设备中的软体，例如一些服务商提供给用户的网页页面，也可以为该些服务商提供给用户的应用。具体的，所述客户端01可以用于对搭载在所述服务器02上的数据调度系统中配置非通知型任务和通知型任务，可以用于对搭载在所述服务器03上的业务系统中配置业务服务逻辑。此外，所述客户端01还可以用于在数据调度系统中或消息通知系统的注册中心中增删、修改或查询注册信息。

具体的，所述服务器02和所述服务器03可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(ContentDeliveryNetwork，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。所述服务器02和所述服务器03可以包括有网络通信单元、处理器和存储器等等。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。具体的，所述服务器02可以用于运行数据调度系统，产生通知任务的任务消息，所述服务器03可以运行业务系统，接收通知任务的任务消息以执行对应的后续业务服务。所述服务器02和所述服务器03之间可以通过消息组件通信连接。

本申请实施例还可以结合云技术实现，云技术(Cloud technology)是指在广域网或局域网内将硬件、软件及网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也可理解为基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术及应用技术等的总称。云技术需要以云计算作为支撑。云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。具体地，所述服务器02、所述服务器03和数据库位于云端，所述服务器02或所述服务器03可以是实体机器，也可以是虚拟化机器。

以下介绍本申请提供的一种消息通知方法。图2是本申请实施例提供的一种消息通知方法的流程图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。请参照图2，本申请实施例提供的一种消息通知方法的执行主体可以为系统间的消息通知组件、装置或消息系统等，所述方法可以包括如下步骤：

S210：获取至少一个通知任务的任务消息，将所述任务消息发往分布式消息队列；所述分布式消息队列包括对应多个消息主题的多个消息队列。

在服务器数据运营领域，数据量大且数据应用场景多样，频繁地涉及到数据调度系统和业务系统的交互，主要是需要在数据调度系统中的某个任务节点完成后通知业务系统以触发业务系统执行某个业务服务。在数据调度系统中，一个任务是在特定环境下运行的一个程序或命令，也可以称为作业(Job)，任务可以分为通知型任务和非通知型任务。示例性的，在数据仓库的调度系统中，一个任务可以是一个数据集的抽取程序或一个报表的生成程序等，非通知型任务可以包括数据入库任务、离线计算任务、数据出库任务等，其中数据入库任务是将各种数据源(如mySQL)接入到数据仓库中；离线计算任务是使用Hive(基于Hadoop的一个数据仓库工具)或者Spark SQL(是Spark用来处理结构化数据的一个模块)编写的脚本任务，按照数据计算模型对数据进行处理；数据出库任务是将数据从数据仓库出库到业务系统的存储区域，如mySQL(一个关系型数据库管理系统)、Clickhouse(一个用于联机分析的列式数据库管理系统)等，以便业务系统可以读取出库后的数据；通知型任务主要是为了实现数据仓库跟外部业务系统的消息通知，以使外部业务系统知道当前的数据计算任务已完成，业务系统在接收到消息后可以进行相应的处理。可以理解的是，在本申请实施例中，通知任务主要完成的是系统之间的消息通知，服务器运营内部的数据调度系统与外部的业务系统是一种应用场景。此外，也可以应用在服务器运营内部的数据调度系统与内部的多个任务执行系统之间的消息通知中。任务流中的多个任务由多个任务执行系统负责执行，且多个任务之间存在依赖关系，数据调度系统需要知道当前任务已执行完成才能向其他任务执行系统发布后续的任务，此时，任务执行系统将任务执行的状态消息发送至数据调度系统以通知数据调度系统已完成对应的任务。

可选地，可以采用一种可视化的任务配置方法，方便基于任务视图对任务及任务依赖关系等进行配置或查看任务的执行状态。图3(1)和图3(2)表示由多个离线计算任务组成的任务视图，可以包含多个任务流，其中空白填充的图形节点为离线计算任务，网格填充的图形节点为通知任务。一个任务视图中通知任务可能是任务视图中的非叶子节点，也可能是某个叶子节点，也即通知任务可以是任务流的中间节点或终止节点，一个任务视图中可以存在一个或多个消息通知任务。通知任务的执行可以视为生产者发布数据。

可选地，配置任务视图时可以设置任务消息的数据格式，示例性的，任务消息的数据采用JSON格式(JavaScript ObjectNotation,对象简谱，是一种轻量级的数据交换格式)，如：

{"id":"1",

"source":"视图通知任务名称"

}；

其中，键值对“id-1”可以视为该通知任务的第一标识数据，以及作为通知任务相关信息的索引依据。

可选地，为了提升消息队列的吞吐量，可以缓存多个通知任务的任务消息，并将多个任务消息批次化或微批次化地发布至分布式消息队列中。可选地，分布式消息队列包括但不限于ZeroMQ、kafka、jafka等。所述分布式消息队列包括对应多个消息主题的多个消息队列，消息队列对应于分布式消息系统集群中的服务器实体。

在本申请的一个实施例中，所述分布式消息队列采用卡夫卡(kafka)消息队列，所述将所述任务消息发往分布式消息队列，可以包括以下步骤：

S211：确定所述任务消息的消息主题。

可以理解的是，消息主题代表消息的类别，生产者在发送消息时必须指定发往哪一个消息主题(以下简称主题)。进一步地，生产者还可以指定消息存储的分区。

S213：将所述任务消息发往与所述任务消息的消息主题对应的消息队列。

可以理解的是，主题在逻辑上可以被认为是一个消息队列，不同主题的消息存储于不同的消息队列中。在物理上，消息是按照文件的方式存储的，消息按照主题的不同存储在不同服务器节点的不同分区文件中。

图4示出了一个主题的分区日志。如图4所示，该主题被划分为了三个分区(Partition)，每个分区是一个有序的、不可变的记录序列，新发布的消息被追加到结构化的日志中。在物理上，这三个分区的分区文件可以存储在不同的服务器节点broker中。

在本申请的一个实施例中，将执行通知任务产生的任务消息存储到区块链中，以方便后续信息的提取存储，图5是本申请实施例提供的一个区块链系统的结构示意图。如图5所示，服务器可以为分布式系统100中的一个节点200，其中该分布式系统可以为区块链系统，该区块链系统可以是由多个节点通过网络通信的形式连接形成的分布式系统，节点之间可以组成点对点(P2P，Peer To Peer)网络，任意形式的计算机设备，比如服务器、客户端300等电子设备都可以通过加入该点对点网络而成为该区块链系统中的一个节点，其中区块链包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

其中区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新兴应用模式，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

S230：确定订阅的消息主题，从与所述订阅的消息主题对应的消息队列中获取目标任务消息。

在本申请实施例中，基于分布式消息队列实现消息的传递，消息传递模式主要有点对点传递模式和发布-订阅的传递模式，如Kafka是一种高吞吐量的分布式发布订阅消息系统，本申请优选发布-订阅的传递模式实现消息的异步传递。从消息队列里边取数据的一般称为消费者，消费者监听订阅的消息主题，从对应的消息队列中拉取数据进行消费。在消费者的程序或进程中预先确定所要订阅的消息主题，订阅的消息主题与任务配置时为通知任务的任务消息设置的消息主题一致。此外，基于本申请实施例中提供的消息重试机制和采用的发布-订阅的消息传递模式，消费者除了订阅通知任务的任务消息主题外，还可以订阅消息重试主题和/或失败主题。

消费者(Consumer)消费消息有pull和push两种方式。在Kafka中采用了pull方式，即Consumer在和broker(broker是消息队列的服务器实体)建立连接之后，主动去拉取消息，该模式的优点是Consumer端可以根据自己的消费能力适时的去拉取消息并处理，且可以控制消息消费的进度。通过循环调用poll()方法拉取数据，poll()方法返回记录的列表，每条记录包含消息的key-value以及主题、分区、位移信息等。

在本申请的一个实施例中，具体地，所述从与所述订阅的消息主题对应的消息队列中获取目标任务消息，可以包括以下步骤：

S231：确定订阅的消息主题。

S233：获取预置的时间参数。

若采用主动拉取数据的方式，当服务器中没有数据时会一直轮询，故可以在消费者的拉取方法中设置时间参数，允许消费者在轮询中阻塞一段时间，等到数据达到后进行拉取。

S235：基于所述时间参数从与所述订阅的消息主题对应的消息队列中进行数据拉取，得到所述目标任务消息。

进一步地，还可以设置数据参数，将到达的数据量满足一定的字节数是再进行拉取。

在本申请实施例中，基于分布式消息队列及发布-订阅的消息传递模式，实现了消息的异步传输，同时解决了系统之间功能耦合的问题，提升处理效率和运营效果。

S250：根据所述目标任务消息中的第一标识数据，从注册中心获取与所述第一标识数据对应的目标注册信息，所述目标注册信息基于所述注册中心的注册页面生成。

在本申请实施例中，消费者拉取数据并得到返回记录的列表，每条记录包含消息的数据内容(如以键值对的数据格式)以及主题、分区、位移信息等。优选地，将数据内容中的一组键值对作为第一标识数据，基于第一标识数据确定所述通知任务或所述任务消息对应的注册信息。

本申请实施例提供了注册中心这一功能模块，所述注册中心设有可视化的注册界面，开发或运维人员可以通过注册界面预先配置通知任务的注册信息或查询注册信息，实现可视化的配置和管控，提高运营管理的效率。注册中心还设有程序接口，供消费者程序调用接口查询注册信息以发送任务消息。所述注册消息表征通知任务的任务消息对应的外部通知方式和通知状态等信息，所述注册信息包括通知任务的第一标识、请求调用的接口地址以及通知任务的任务消息的发送状态等。相比于从服务器后台进行配置的方法，能较小影响服务器运营的进程。注册信息组成的关键数据表可以如表1所示：

表1

Id	Request	Lock
			1	R1	0
2	R2	1
			...	...	...

其中，Id字段可以用于唯一标识一条记录；Request表示请求，可以是要调用的目的接口地址，类如http://{域名}/method_path？p1＝v1&p2＝v2；Lock表示开关，可取值为0或1，0表示请求已经发送，1表示未发送。

在本申请的一个实施例中，具体地，如图6所示，所述从注册中心获取与所述第一标识数据对应的目标注册信息，可以包括以下步骤：

S251：在高速缓存服务器集群中查询是否存在与所述第一标识数据对应的目标注册信息；所述高速缓存服务器集群定时从所述注册中心定同步数据。

S253：若所述高速缓存服务器集群中存在与所述第一标识数据对应的目标注册信息，则从所述高速缓存服务器集群中获取所述目标注册信息。

S255：若所述高速缓存服务器集群中不存在与所述第一标识数据对应的目标注册信息，则调用所述注册中心的接口进行查询，获取与所述第一标识数据对应的目标注册信息。

所述高速缓存服务器集群可以提高服务的响应速度，处理及时性要求高的任务消息时，注册信息同步至缓存中，然后消费者读取。示例性地，所述高速缓存服务器集群可以采用Redis或者Memcache(一套分布式的高速缓存系统)，如Redis是一款出色的缓存服务器，内存级别的键值对数据库，支持丰富的数据结构，数据库操作命令也是很齐全，且Redis操作速度非常快，满足缓存服务器需求。Redis提供单机的分片集群，也可以进行分布式部署，搭建分布式缓存服务。

S270：根据所述目标注册信息确定所述目标任务消息的目的接口地址。

可以理解的是，由目标任务消息的唯一标识确定对应的目标注册信息，所述目标注册信息中记录有所述目标任务消息需发送至的目的接口地址，可以为URL(UniformResource Locator，统一资源定位器)地址，所述目的接口地址与外部的业务服务对应。

S290：向与所述目的接口地址对应的目标业务服务发送所述目标任务消息。

在本申请实施例中，将目标任务消息告知对应的业务服务，通知业务系统执行对应的操作，如在将数据出库完成后，告知外部的业务系统可以在业务系统自己的数据库中读取出库的数据。若所述目的接口地址为URL地址，则可以通过调用httpclient服务将所述目标任务消息中的数据内容发送给URL地址对应的业务服务，业务服务负责实际的业务逻辑。

在本申请实施例中，采用分布式消息队列和发布-订阅的消息传递模式，可以设计消息重试或告警机制以保证消息的送达。具体地，当订阅的主topic消息消费失败，消费者不会对这条消息进行阻塞式消费，而是可以将给消息的副本消息写入重试topic中，由其他消费者消费重试topic中的消息；当重试topic中消息按预设策略重试消费指定次数仍发送失败，则将该副本消息写入失败topic种，失败topic中的消息会通过手动的方式进行处理，以此实现无阻塞的重试逻辑，保证任务消息的送达。

在本申请的一个实施例中，具体地，所述向与所述目标接口地址对应的目标业务服务发送所述目标任务消息，可以包括以下步骤：

S291：若未能将所述目标任务消息成功发送，确定未能成功发送的原因类型。

在本申请的一个实施例中，消息处理可能会失败，其中一些原因是永久性问题，例如数据库约束失败或消息格式无效。此时重试消息处理可以是一种有效的解决方案。当订阅的主topic中的消息消费失败，则按消费失败的类型进行处理，消费失败的类型分为3种：

类型1：程序运行时异常、数据库持久化异常、网络超时异常等；

类型2：业务处理失败(可恢复)、业务要求重试等；

类型3：参数、数据不合法等。

S293：根据所述未能成功发送的原因类型进行重试或告警。

在本申请的一个实施例中，如图7所示，针对类型1，当未能成功发送则会产生告警，触发系统自动终止消费，并需要通知用户手动重启消费；针对类型2，当未能成功发送则会将发送失败的任务消息写入重试topic，待重新被消费；针对类型3，当未能成功发送则会产生告警，并将消息写入失败topic，用户收到告警会对失败topic的消息进行手动处理。其中主topic存放主要的任务消息，消息量占比99.95％；重试topic存放需要重试的消息，消息量占比小于0.05％；失败topic，用于存放发送失败的消息,消息量占比小于0.05％。

具体地，当目标任务消息需要写入重试topic待重新被消费时，如图8所示，所述步骤S293可以包括以下步骤：

S2931：根据所述目标任务消息生成所述目标任务消息副本。

S2933：将所述目标任务消息副本发往与预设的消息重试主题对应的消息队列。

S2935：基于预设的重试策略，从与所述消息重试主题对应的消息队列中读取所述目标任务消息并将所述所述目标任务消息进行再次发送。

具体地，所述预设的重试策略可以表现为：按递增延迟周期时间消费重试topic的消息，消费失败则重新放入重试主题，最多重试n次，n次中有一次成功则不再重试，超过n次放入失败主题。如图7中所示，递增周期时间可以为5秒、10秒、20秒，n取值为3。

在本申请的一个实施例中，在所述将所述目标任务消息发送至与所述目的接口地址对应的目标业务服务后，所述方法还可以包括：

通知所述注册中心已完成消息发送，以使所述注册中心更新所述目标注册信息。

具体地，在目标任务消息成功发送后，修改目标注册信息中表征消息发送状态的属性，如将Lock值由1改为0(0表示已发送，1表示未发送)。

图9是一种具体的基于定时任务的消息通知方法示意图，在如图9所示的消息通知架构下，主要步骤包括：

1.编写业务服务逻辑；

2.在任务视图任务编写和配置非通知型任务；

3.在任务视图配置通知任务；

4.配置定时任务；

5.通知任务节点写状态表，状态表可以如下表所示：

表2

Id	请求Request	标志位
			1	R1	0
2	R2	1
			...	...	...

其中：Id不重复且唯一标识一条记录；R2为要调用的请求(格式可以为http://{域名}/method_path？p1＝v1&p2＝v2)；标志位表示通知任务的执行状态(可以用1表示待执行，0表示已经执行)；

6.定时任务处理器处理：

(1)定时轮询查询状态表，对应图9中第6步；

(2)取出标志位为1的记录，对应图9第7步；

(3)发送记录中对应的请求，对应图9第8、9步；

(4)将状态表对应记录标志位置修改为0，对应图9第10步，修改后的状态表可以如下表3所示：

表3

Id	请求Request	标志位
			1	R1	0
2	R2	0
			...	...	...

7.重复图9中的第(1)～(10)步。

可以看到，基于定时任务的消息通知方法容易出现功能耦合的问题，且不支持消息失败重试，无法提供可视化的配置和管控。

图10是本申请提供的一种基于kafka消息队列的消息通知方法的流程示意图。结合本申请提供的方法实施例，在离线计算的数据调度平台的基础上，引入kafka消息队列，设计一套新的消息通知机制，解决功能耦合的问题；且支持重试和告警机制，提高了可靠性；同时提供了动态配置和可视化的能力，提升服务器运营领域的数据运营处理效率，一来可以提升服务器运营商的服务质量，二来可以为业务稳定运行提供支持，满足客户的需要。

如图10中所示，消息队列选用的是kafka，在这里主要用来存储通知任务的消息数据，可以采用json格式；Kafka Consumer是消费者程序，它的主要作用是通过监听kafka指定的topic消费消息。本申请的一个实施例还提供了消费者程序的一个实例，实例的程序内容可以如下所示：

可以看到，本申请提供的方案引入分布式消息队列，发布者的消息根据消息主题分开存储，订阅者只需订阅消息的主题即可消费数据而不必关心数据的物理地址，可以解决任务调度和消息通知、任务调度与业务服务的功能耦合的问题；本申请提供的方案可以通过消息重试和告警措施，提高消息的发送成功率，提升消息通知的可靠性；本申请提供的方案通过设置注册中心提供可视化的动态配置和管控，提升服务器运营的处理效率，助力智能化运营，降低了运营成本。

本申请实施例还提供了一种消息通知装置1100，如图11所示，所述装置可1100以包括：

获取发送模块1110，用于获取至少一个通知任务的任务消息，将所述任务消息发往分布式消息队列；所述分布式消息队列包括对应多个消息主题的多个消息队列；

第二获取模块1120，用于确定订阅的消息主题，从与所述订阅的消息主题对应的消息队列中获取目标任务消息；

第三获取模块1130，用于根据所述目标任务消息中的第一标识数据，从注册中心获取与所述第一标识数据对应的目标注册信息，所述目标注册信息基于所述注册中心的注册页面生成；

地址确定模块1140，用于根据所述目标注册信息确定所述目标任务消息的目的接口地址；

消息发送模块1150，用于向与所述目的接口地址对应的目标业务服务发送所述目标任务消息。

在本申请的一个实施例中，所述获取发送模块1110可以包括：

第一主题确定单元，用于确定所述任务消息的消息主题；

发送单元，用于将所述任务消息发往与所述任务消息的消息主题对应的消息队列。

在本申请的一个实施例中，所述第二获取模块1120可以包括：

第二主题确定单元，用于确定订阅的消息主题；

时间参数获取单元，用于获取预置的时间参数；

数据拉取单元，用于基于所述时间参数从与所述订阅的消息主题对应的消息队列中进行数据拉取，得到所述目标任务消息。

在本申请的一个实施例中，所述第三获取模块1130可以包括：

缓存获取单元，用于若高速缓存服务器集群中存在与所述第一标识数据对应的目标注册信息，则从所述高速缓存服务器集群中获取所述目标注册信息；所述高速缓存服务器集群定时从所述注册中心定同步数据；

注册中心获取单元，用于若所述高速缓存服务器集群中不存在与所述第一标识数据对应的目标注册信息，则调用所述注册中心的接口进行查询，获取与所述第一标识数据对应的目标注册信息。

在本申请的一个实施例中，所述消息发送模块1150可以包括：

原因确定单元，用于若未能将所述目标任务消息成功发送，确定未能成功发送的原因类型；

重试告警单元，用于根据所述未能成功发送的原因类型进行重试或告警。

在本申请的另一个实施例中，所述重试告警单元还可以包括：

副本生成子单元，用于根据所述目标任务消息生成所述目标任务消息副本；

重存储子单元，用于将所述目标任务消息副本发往与预设的消息重试主题对应的消息队列；

重试子单元，用于基于预设的重试策略，从与所述消息重试主题对应的消息队列中读取所述目标任务消息并将所述所述目标任务消息进行再次发送。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请实施例提供了一种计算机设备，该计算机设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的一种消息通知方法。

图12示出了一种用于实现本申请实施例所提供的一种消息通知方法的设备的硬件结构示意图，所述设备可以参与构成或包含本申请实施例所提供的装置或系统。如图12所示，设备12可以包括一个或多个(图中采用1202a、1202b，……，1202n来示出)处理器1202(处理器1202可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1204、以及用于通信功能的传输装置1206。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图12所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备12还可包括比图12中所示更多或者更少的组件，或者具有与图12所示不同的配置。

应当注意到的是上述一个或多个处理器1202和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备12(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器1204可用于存储应用软件的软件程序以及模块，如本申请实施例中所述的方法对应的程序指令/数据存储装置，处理器1202通过运行存储在存储器1204内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种消息通知方法。存储器1204可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1204可进一步包括相对于处理器1202远程设置的存储器，这些远程存储器可以通过网络连接至设备12。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置1206用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备12的通信供应商提供的无线网络。在一个实例中，传输装置1206包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置1206可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与设备12(或移动设备)的用户界面进行交互。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质可设置于服务器之中以保存用于实现方法实施例中一种消息通知方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的一种消息通知方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本发明实施例还提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施方式中提供的消息通知方法。

由上述本申请提供的一种消息通知方法、装置、介质及设备的实施例可见：

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

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种消息通知方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述将所述任务消息发往分布式消息队列，包括：

确定所述任务消息的消息主题；

将所述任务消息发往与所述任务消息的消息主题对应的消息队列。

3.根据权利要求1所述的方法，其特征在于，所述确定订阅的消息主题，从与所述订阅的消息主题对应的消息队列中获取目标任务消息，包括：

确定订阅的消息主题；

获取预置的时间参数；

基于所述时间参数从与所述订阅的消息主题对应的消息队列中进行数据拉取，得到所述目标任务消息。

4.根据权利要求1所述的方法，其特征在于，所述根据所述目标任务消息中的第一标识数据，从注册中心获取与所述第一标识数据对应的目标注册信息，包括：

若高速缓存服务器集群中存在与所述第一标识数据对应的目标注册信息，则从所述高速缓存服务器集群中获取所述目标注册信息；所述高速缓存服务器集群定时从所述注册中心定同步数据；

若所述高速缓存服务器集群中不存在与所述第一标识数据对应的目标注册信息，则调用所述注册中心的接口进行查询，获取与所述第一标识数据对应的目标注册信息。

5.根据权利要求1所述的方法，其特征在于，所述向与所述目的接口地址对应的目标业务服务发送所述目标任务消息，包括：

若未能将所述目标任务消息成功发送，确定未能成功发送的原因类型；

根据所述未能成功发送的原因类型进行重试或告警。

6.根据权利要求5所述的方法，其特征在于，所述根据所述原因类型进行重试，包括：

根据所述目标任务消息生成所述目标任务消息副本；

将所述目标任务消息副本发往与预设的消息重试主题对应的消息队列；

基于预设的重试策略，从与所述消息重试主题对应的消息队列中读取所述目标任务消息并将所述所述目标任务消息进行再次发送。

7.根据权利要求1所述的方法，其特征在于，在所述将所述目标任务消息发送至与所述目的接口地址对应的目标业务服务后，所述方法还包括：

8.一种消息通知装置，其特征在于，所述装置包括：

9.一种计算可读机存储介质，其特征在于，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如权利要求1至7中任一项所述的一种消息通知方法。

10.一种计算机设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由所述处理器加载并执行以实现如权利要求1至7中任一项所述的一种消息通知方法。