CN114629904B - 一种分布式事件的处理方法、系统、设备及介质 - Google Patents

Abstract

本发明提供的一种分布式事件的处理方法、系统、设备及介质，方法包括以下步骤：获取客户端发送的订阅请求；对订阅请求进行解码，从解码后的订阅请求中提取得到逻辑关键词；建立与分布式实时消息平台的第一通信连接，根据逻辑关键词通过第一通信连接获取得到候选订阅事件；通过回调处理函数对候选订阅事件进行筛选，得到目标订阅事件；将目标订阅事件发送至客户端，以使客户端根据目标订阅事件进行业务逻辑处理；提供了基本的消息分区的能力，同时也提供了延时投递事件的功能，使得分布式系统的开发过程更加便捷轻松，分布式系统也更为灵活，扩展性强，可以适用于更多的应用场景可广泛应用于分布式系统技术领域。

Description

一种分布式事件的处理方法、系统、设备及介质

技术领域

本发明涉及分布式系统技术领域，尤其是一种分布式事件的处理方法、系统、设备及存储介质。

背景技术

分布式系统(distributed system)是建立在网络之上的软件系统，由于软件的特性，所以分布式系统具有高度的内聚性和透明性，因此，网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统)，而不是硬件。

在相关技术中，在分布式系统中存在大量使用消息中间件解耦应用逻辑的场景，现有的消息中间件很多都提供了发布-订阅语义的接口，但是对于一般的应用来说，这些消息中间件并没有提供一个易于配置和使用的基于事件总线语义的接口，同时，使用这些中间件时，应用还需要关注不同事件的路由，分区等细节；总之，相关技术中的分布式系统，对于开发者而言存在其开发配置过程过于复杂繁琐，现有的分布式系统的开发过程不够友好。

发明内容

有鉴于此，为至少部分解决上述技术问题之一，本发明实施例目的在于提供一种简单易用，可以隐藏复杂的内部消息路由的一种分布式事件的处理方法；与此同时，本申请技术方案还提供能够对应实现该方法的系统、设备及计算机可读写的存储介质。

一方面，本申请技术方案提供了一种由分布式系统中的服务端所执行的分布式事件的处理方法，方法包括以下步骤：

获取客户端发送的订阅请求；

对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；

通过回调处理函数对所述候选订阅事件进行筛选，得到目标订阅事件；

将所述目标订阅事件发送至客户端，以使客户端根据所述目标订阅事件进行业务逻辑处理。

在本申请方案的一种可行的实施例中，在将所述目标订阅事件发送至客户端这一步骤之后，所述处理方法包括：

获取所述客户端的服务响应信息，所述服务响应信息在业务逻辑处理完成后生成得到；

根据所述服务响应信息，通过所述回调处理函数对订阅事件进行二次处理，对所述候选订阅事件进行更新；

从更新后的所述候选订阅事件提取得到所述目标订阅事件。

在本申请方案的一种可行的实施例中，处理方法还包括：

获取事件报文；

从所述事件报文中提取得到事件数据，将所述事件数据进行编码得到第一结构消息；

从节点池中筛选得到存活的目标节点；

向所述目标节点投递所述第一结构消息；

将所述事件报文的标识信息反馈至所述客户端。

在本申请方案的一种可行的实施例中，在从所述事件报文中提取得到事件数据这一步骤之后，所述方法包括：

对所述事件数据进行基本属性校验；

确定校验通过，根据所述事件数据生成所述标识信息。

另一方面，本申请技术方案提供了一种由分布式系统中的服务端所执行的分布式事件的处理方法：

所述处理方法包括以下步骤：

根据预设协议构建第二通信连接；

通过所述第二通信连接向服务端发送订阅请求，以使服务端根据所述订阅请求返回目标订阅事件；

根据所述目标订阅事件进行业务逻辑处理；

其中，以使服务端根据所述订阅请求返回目标订阅事件这一步骤包括：

使服务端对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

使服务端建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；

使服务端通过回调处理函数对所述候选订阅事件进行筛选，得到目标订阅事件。

在本申请方案的一种可行的实施例中，在根据所述目标订阅事件进行业务逻辑处理这一步骤之后，所述处理方法还包括：

确定业务逻辑处理完成，生成服务响应信息；

将所述服务响应信息发送至所述服务端，以使所述服务端通过处理函数对订阅进行二次处理，对所述候选订阅事件进行更新；

获取从更新后的候选订阅事件中提取得到的目标订阅事件。

在本申请方案的一种可行的实施例中，所述处理方法包括以下步骤：

获取事件数据，将所述事件数据进行编码得到事件报文；

将所述事件报文发送至服务端，以使所述服务端将所述事件报文投递至目标节点；

接收所述服务端反馈事件报文投递完成后的标识信息；

其中，以使所述服务端将所述事件报文投递至目标节点的步骤包括：

使服务端从所述事件报文中提取得到事件数据；将所述时间数据进行编码得到第一结构消息；

使服务端从节点池中筛选得到存活的目标节点；

使服务端向所述目标节点投递所述第一结构消息。

另一方面，本申请技术方案还提供了一种分布式事件的处理系统，包括客户端和服务端；

所述服务端包括：

第一数据传输单元，用于获取客户端发送的订阅请求，和/或将目标订阅事件发送至客户端；

数据解码单元，用于对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

实时消息单元，用于建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；并通过回调处理函数对所述候选订阅事件进行筛选，得到目标订阅事件；

所述客户端包括：

第二数据传输单元，用于根据预设协议构建第二通信连接；并通过所述第二通信连接向服务端发送订阅请求，

事件处理单元，用于根据所述目标订阅事件进行业务逻辑处理。

另一方面，本发明的技术方案还提供一种分布式事件的处理设备，其包括：

至少一个处理器；

至少一个存储器，用于存储至少一个程序；

当至少一个程序被至少一个处理器执行，使得至少一个处理器运行如前面所述的一种分布式事件的处理方法。

另一方面，本发明的技术方案还提供了一种存储介质，其中存储有处理器可执行的程序，处理器可执行的程序在由处理器执行时用于运行如前面所述的一种分布式事件的处理方法。

本发明的优点和有益效果将在下面的描述中部分给出，其他部分可以通过本发明的具体实施方式了解得到：

本申请的技术方案本申请技术方案通过从订阅请求中提取的到逻辑关键词，再通过分布式实时消息平台，基于逻辑关键词获取得到候选订阅事件，方案可以仅仅通过简单易用的接口，隐藏复杂的内部消息路由；此外，在得到候选订阅事件，方案还通过回调处理函数对所述候选订阅事件进行筛选，进而得到目标订阅事件；方案利用消息中间件，即分布式实时消息平台的扩展性，提供了基本的消息分区的能力，同时本方案也提供了延时投递事件的功能，使得分布式系统的开发过程更加便捷轻松，分布式系统也更为灵活，扩展性强，可以适用于更多的应用场景。

附图说明

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

图1是本发明实施例中订阅事件的步骤流程图；

图2是本发明实施例中发布事件的步骤流程图。

具体实施方式

下面详细描述本发明的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。对于以下实施例中的步骤编号，其仅为了便于阐述说明而设置，对步骤之间的顺序不做任何限定，实施例中的各步骤的执行顺序均可根据本领域技术人员的理解来进行适应性调整。

基于前述背景技术中所指出的相关技术中所存在的不足，本申请的技术方案通过简单易用的接口，对使用者隐藏了复杂的内部消息路由，通过利用消息中间件的扩展性，提供了基本的消息分区的能力，同时也可以延时投递事件的支持。进而，一方面，如图1所示，本申请的实施例提供了一种分布式事件的处理方法，该处理方法可以由分布式系统中的服务端执行，方法包括步骤S100-S500：

S100、获取客户端发送的订阅请求；

具体在实施例中，可以采用Android事件发布/订阅轻量级框架，例如EventBus框架，进而在实施例的分布式系统中，客户端即是指EventBus客户端；服务端即是指EventBus服务端，在实施例中，EventBus可以代替Android传统的接口函数，在线程之间传递数据，执行相应的数据交互方法，其属于一类发布订阅设计模式，代码内容更为简洁。首先，在实施例中由EventBus客户端通过远程过程调用(remote procedure call，gRPC)建立HTTP/2连接，其中，gRPC框架能够提供了一套机制，使得应用程序之间可以进行通信，而且也遵从server/client模型，使用的过程中，EventBus客户端调用server端提供的接口就像是调用本地的函数一样，且gRPC框架使用http作为底层的传输协议。实施例在建立EventBus客户端与EventBus服务端建立HTTP/2连接能够进行数据交换之后，EventBus客户端根据用户的访问需求或者执行指令，生成相应的订阅请求SubReq，其中，订阅请求可以包括EventBus客户端的ID以及需要订阅的事件类型列表，并将这一订阅请求发送至EventBus服务端，EventBus服务端在接收到该订阅请求之后，执行后续的处理步骤。

S200、对订阅请求进行解码，从解码后的订阅请求中提取得到逻辑关键词；

具体在实施例中，EventBus服务端在接收到EventBus客户端发送的订阅请求之后，首先对这一订阅请进行解码处理，具体的解码过程，根据步骤S100中所选择的通信协议确定，例如实施例中建立HTTP/2连接，其解码过程需要根据协议的帧格式进行提取得到有效载荷，并通过解压等转码等必要的处理得到EventBus客户端的ID以及需要订阅的事件类型列表；在一些必要的实施例中，可以对解码后得到的消息进行必要的验证过程。实施例在得到解码后的消息之后，根据前述的需要订阅的事件类型列表确定逻辑关键词topic；更为具体的，在实施例中topic是分布式实时消息平台NSQ消息发布的逻辑关键词，可以理解为人为定义的一种消息类型。当程序初次发布带topic的消息时，如果topic不存在，则会在nsqd中创建。

S300、建立与分布式实时消息平台的第一通信连接，根据逻辑关键词通过第一通信连接获取得到候选订阅事件；

具体在实施例中，EventBus服务端与NSQ建立连接，订阅EventBus所属的topic，建立回调处理器；其中，NSQ是一个基于Go语言的分布式实时消息平台，它基于MIT开源协议发布，是一款简单易用的消息中间件；NSQ可用于大规模系统中的实时消息服务，并且能够处理数亿级别的消息，为在分布式环境下运行的去中心化服务提供一个强大的基础架构。在实施例中，EventBus服务端作为NSQ的producer，即消息的生产者/发布者；而所建立的第一通信连接是指NSQ的channel，即消息传递的通道。更为具体的，实施例中，producer通过HTTP API将消息发布到nsqd的指定topic，可以采用pub/mpub两种方式，pub发布一个消息，mpub一个往返发布多个消息；producer也可以通过nsqd客户端的TCP接口将消息发布给nsqd的指定topic。当生产者producer初次发布带topic的消息给nsqd时，如果topic不存在，则会在nsqd中创建topic；在实施例需要获取某个topic的消息时，可以订阅一个单独命名的nsqd中还不存在的channel，NSQ将topic对应的数据或者消息通过这一channel回传至EventBus服务端或者其他目标consumer，即消息的消费者。

S400、通过回调处理函数对候选订阅事件进行筛选，得到目标订阅事件；

具体在实施例中，EventBus服务端中可以建立回调处理器，用于运行回调处理函数，回调处理器在收到NSQ消息推送时，挑选订阅的事件类型，丢弃不感兴趣的事件；其中，不感兴趣的事件可以通过与topic进行筛选匹配，将匹配程度不满足预设阈值的消息或者事件进行剔除从而达到剔除不感兴趣事件的目的。实施例中EventBus服务端从NSQ所接收到的事件均可以作为候选订阅事件，在筛除掉不感兴趣的事件之后，所保留下来的订阅事件则为目标订阅事件。

在实施例中，通过回调处理函数或者回调处理器可以实现将功能定义与功能分开，属于解耦合的设计思想，示例性地，在Java中回调是通过接口来实现的，作为一种系统架构，必须要有自己的运行环境，且需要为用户提供实现接口；实现依赖于客户，进而可以达到接口统一，实现不同系统通过在不同的状态下回调，进一步达到接口和实现的分离。

S500、将目标订阅事件发送至客户端，以使客户端根据目标订阅事件进行业务逻辑处理。

具体在实施例中，EventBus客户端收到目标订阅事件后，根据这一目标订阅事件进行业务逻辑处理。

在一些可选择的实施例中，方法在步骤S500将目标订阅事件发送至客户端这一过程之后，实施例的处理方法还可以包括步骤S600-S700：

S600、获取客户端的服务响应信息；

其中，服务响应信息在业务逻辑处理完成后生成得到

S700、根据服务响应信息，通过回调处理函数对订阅事件进行二次处理，对候选订阅事件进行更新；

S800、从更新后的候选订阅事件提取得到目标订阅事件；

具体在实施例中，EventBus客户端在接收到目标订阅事件之后，进行相应的业务逻辑处理，并且以AckReq响应EventBus服务端处理结果；待EventBus服务端接收到EventBus客户端的AckReq响应之后，根据AckReq的处理结果决定是否需要重试事件处理；如若确定需要进行重试事件处理，即需要对目标订阅事件进行重新筛选，在实施例中，系统可以通过在步骤S300中构建的channel重新获取一定数量的事件消息，对候选订阅事件的总集进行更新，并再次调用回调处理器，从更新后的候选订阅事件中筛选得到目标订阅事件。

本申请实施例不仅可以通过gRPC的双向流实现，为了简化EventBus内部的处理逻辑，协议上还使用了request/response的模式，事件流处理过程中，需要等待上一个事件的应答才会继续处理下一个事件。方案的实施例可以限制了事件处理的并行度，但是开发者也可以使用不同线程subscribe不同事件的方式来提高并行处理的通量。subscribe接口依赖业务逻辑的异常来判断事件是否成功处理，发生异常时，事件会有重试的机会。

在一些可以选择的实施例中，在EventBus客户端通过publish接口发布事件的情况下，如图2所示，方法可以包括步骤T100-T500：

T100、获取事件报文；

T200、从事件报文中提取得到事件数据，将事件数据进行编码得到第一结构消息；

T300、从节点池中筛选得到存活的目标节点；

T400、向目标节点投递第一结构消息；

T500、将事件报文的标识信息反馈至客户端；

具体在实施例中，与订阅事件的过程相类似的，实施例中EventBus客户端通过gRPC与EventBus服务端建立HTTP/2连接，然后EventBus客户端将事件数据以protobuf编码后，再封装成gRPC的报文结构，通过HTTP/2的连接发送到EventBus服务端，EventBus服务端接收到事件报文后，对事件数据进行必要的基本属性的校验，生成唯一的事件ID，进而EventBus服务端将事件数据编码为NSQ的消息结构；然后，根据EventBus服务端根据本地记录的上次投递过的节点偏移确定下一个节点；需要说明的是，实施例中的节点，包括但不限于在实施例分布式系统中的客户端或者其他服务端等设备。在确定下一个节点之后，EventBus服务端从NSQ节点池中选择下一个节点，发送ping报文以确定节点是否存活；若发送ping报文之后，确定当前节点处于异常状态，则实施例重复确定下一个节点的步骤，重新从NSQ节点池中选择一个新的节点，直至有可用的节点，当所有节点都进行尝试了之后，仍未获得可用的节点，则EventBus服务端判定为当前系统异常，终止事件投递。若EventBus服务端确定了合适可用的节点后，将事件数据编码为NSQ的消息报文并投递，投递过程中EventBus服务端通过gRPC报文返回事件ID给客户端。

在一些可选择的实施例中，方法中步骤T200从事件报文中提取得到事件数据这一过程，可以包括步骤T210-T220：

T210、对事件数据进行基本属性校验；

T220、确定校验通过，根据事件数据生成标识信息；

具体在实施例中，EventBus服务端接收到事件报文后，对事件数据进行必要的基本属性的校验，生成唯一的事件ID；其中，基本属性的校验过程可以包括对事件数据的完整程度进行校验确定时间数据中的数据格式均符合要求、不存在缺失、空值记录等等。

本申请实施例采用阻塞式的事件接口，更加适用于在事务块中调用，由于本申请方案使用了gRPC的缘故，外层的gRPC请求处理cancel或者deadline到期都会终止事件的publish，这种情况会导致publish接口抛出异常，触发事务回滚，很大程度上能保证跨服务的数据一致性。异步接口和publish接口不同，本方案实施例需要确保外部调用逻辑的结束或提前终止不会导致事件publish也被终止。本方案的实施例在gRPC场景下，因为有gRPCcontext的存在，不管是EventBus服务端请求handler还是客户端调用，外层的gRPC调用的终止会传播到内层调用，导致内层调用也被终止(即使是跨线程的)，不符合异步接口的设计原则，因此在异步接口里，实施例可以采用context的fork，确保内层调用不受影响，在具体的实施场景中，可以根据使用场景来选择是否使用异步接口。

相对应地，第二方面，本申请技术方案还提供了一种分布式事件的处理方法，该处理方法可以由分布式系统中的客户端执行，该方法可以包括步骤X100-X300：

X100、根据预设协议构建第二通信连接；

其中，第二通信连接由EventBus客户端通过远程过程调用(remote procedurecall，gRPC)建立HTTP/2连接。

X200、通过第二通信连接向服务端发送订阅请求，以使服务端根据订阅请求返回目标订阅事件；

X300、根据目标订阅事件进行业务逻辑处理；

在实施例中，方法步骤X200以使服务端根据订阅请求返回目标订阅事件这一过程可以包括X210-X230：

X210、使服务端对订阅请求进行解码，从解码后的订阅请求中提取得到逻辑关键词；

X220、使服务端建立与分布式实时消息平台的第一通信连接，根据逻辑关键词通过第一通信连接获取得到候选订阅事件；

X230、使服务端通过回调处理函数对候选订阅事件进行筛选，得到目标订阅事件。

在一些可选择的实施例中，在方法步骤X300根据目标订阅事件进行业务逻辑处理这一过程之后，还可以包括步骤X310-X330：

X310、确定业务逻辑处理完成，生成服务响应信息；

X320、将服务响应信息发送至服务端，以使服务端通过处理函数对订阅进行二次处理，对候选订阅事件进行更新；

X330、获取从更新后的候选订阅事件中提取得到的目标订阅事件。

除此之外，在一些可以选择的实施例中，在事件发布的过程中，客户端所执行的处理方法还可以包括步骤Y100-Y300：

Y100、获取事件数据，将事件数据进行编码得到事件报文；

Y200、将事件报文发送至服务端，以使服务端将事件报文投递至目标节点；

Y300、接收服务端反馈事件报文投递完成后的标识信息；

在实施例中，步骤Y200以使服务端将事件报文投递至目标节点的过程可以包括步骤Y210-Y230：

Y210、使服务端从事件报文中提取得到事件数据；将时间数据进行编码得到第一结构消息；

Y220、使服务端从节点池中筛选得到存活的目标节点；

Y230、使服务端向目标节点投递第一结构消息。

实施例中，使用gRPC的双向流实现，为了简化EventBus内部的处理逻辑，协议上使用了request/response的模式，事件流处理过程中，需要等待上一个事件的应答才会继续处理下一个事件。这种方式限制了事件处理的并行度，但是开发者也可以使用不同线程subscribe不同事件的方式来提高并行处理的通量。subscribe接口依赖业务逻辑的异常来判断事件是否成功处理。发生异常时，事件会有重试的机会。

此外，实施例中阻塞式的事件接口适用于在事务块中调用，因为使用了gRPC的缘故，外层的gRPC请求处理cancel或者deadline到期都会终止事件的publish，这种情况会导致publish接口抛出异常，触发事务回滚，很大程度上能保证跨服务的数据一致性。异步接口和publish接口不同，实施例需要确保外部调用逻辑的结束或提前终止不会导致事件publish也被终止。在gRPC场景下，因为有gRPC context的存在，不管是服务端请求handler还是客户端调用，外层的gRPC调用的终止会传播到内层调用，导致内层调用也被终止(即使是跨线程的)，这不符合异步接口的设计原则，因此在异步接口里，实施例采用了context的fork，确保内层调用不受影响。在实施过程中根据具体使用场景来选择是否使用异步接口。

第三方面，本申请的技术方案还提供了一种分布式事件的处理系统，该系统包括两个主要的对象：客户端和服务端。

其中，服务端包括：

第一数据传输单元，用于获取客户端发送的订阅请求，和/或将目标订阅事件发送至客户端；

数据解码单元，用于对订阅请求进行解码，从解码后的订阅请求中提取得到逻辑关键词；

实时消息单元，用于建立与分布式实时消息平台的第一通信连接，根据逻辑关键词通过第一通信连接获取得到候选订阅事件；并通过回调处理函数对候选订阅事件进行筛选，得到目标订阅事件；

客户端包括：

第二数据传输单元，用于根据预设协议构建第二通信连接；并通过第二通信连接向服务端发送订阅请求，

事件处理单元，用于根据目标订阅事件进行业务逻辑处理。

第四方面，本申请的技术方案还提供一种分布式事件的处理设备，其包括：

至少一个处理器；至少一个存储器，该存储器用于存储至少一个程序；当至少一个程序被至少一个处理器执行，使得至少一个处理器运行如第一方面中的一种分布式事件的处理方法。

本发明实施例还提供了一种存储介质内存储有程序，程序被处理器执行，实现上述一种分布式事件的处理方法。

从上述具体的实施过程，可以总结出，本发明所提供的技术方案相较于现有技术存在以下优点或优势：

1.本申请技术方案通过提供简单易用的接口，对使用者隐藏了复杂的内部消息路由，利用已有的消息中间件的扩展性，提供了基本的消息分区的能力，同时本发明也提供了延时投递事件的支持功能。

在一些可选择的实施例中，在方框图中提到的功能/操作可以不按照操作示图提到的顺序发生。例如，取决于所涉及的功能/操作，连续示出的两个方框实际上可以被大体上同时地执行或所述方框有时能以相反顺序被执行。此外，在本发明的流程图中所呈现和描述的实施例以示例的方式被提供，目的在于提供对技术更全面的理解。所公开的方法不限于本文所呈现的操作和逻辑流程。可选择的实施例是可预期的，其中各种操作的顺序被改变以及其中被描述为较大操作的一部分的子操作被独立地执行。

此外，虽然在功能性模块的背景下描述了本发明，但应当理解的是，除非另有相反说明，功能和/或特征中的一个或多个可以被集成在单个物理装置和/或软件模块中，或者一个或多个功能和/或特征可以在单独的物理装置或软件模块中被实现。还可以理解的是，有关每个模块的实际实现的详细讨论对于理解本发明是不必要的。更确切地说，考虑到在本文中公开的装置中各种功能模块的属性、功能和内部关系的情况下，在工程师的常规技术内将会了解该模块的实际实现。因此，本领域技术人员运用普通技术就能够在无需过度试验的情况下实现在权利要求书中所阐明的本发明。还可以理解的是，所公开的特定概念仅仅是说明性的，并不意在限制本发明的范围，本发明的范围由所附权利要求书及其等同方案的全部范围来决定。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

以上是对本发明的较佳实施进行了具体说明，但本发明并不限于上述实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (10)

1.一种分布式事件的处理方法，其特征在于，所述处理方法包括以下步骤：

获取客户端发送的订阅请求；

对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；

通过回调处理函数的调用，以使所述逻辑关键词和所述候选订阅事件进行筛选匹配，并剔除匹配程度不满足预设阈值的候选订阅事件，得到目标订阅事件；

将所述目标订阅事件发送至客户端，以使客户端根据所述目标订阅事件进行业务逻辑处理。

2.根据权利要求1所述的一种分布式事件的处理方法，其特征在于，在将所述目标订阅事件发送至客户端这一步骤之后，所述处理方法包括：

获取所述客户端的服务响应信息，所述服务响应信息在业务逻辑处理完成后生成得到；

根据所述服务响应信息，通过所述回调处理函数对订阅事件进行二次处理，对所述候选订阅事件进行更新；

从更新后的所述候选订阅事件提取得到所述目标订阅事件。

3.根据权利要求1所述的一种分布式事件的处理方法，其特征在于，处理方法还包括：

获取事件报文；

从所述事件报文中提取得到事件数据，将所述事件数据进行编码得到第一结构消息；

从节点池中筛选得到存活的目标节点；

向所述目标节点投递所述第一结构消息；

将所述事件报文的标识信息反馈至所述客户端。

4.根据权利要求3所述的一种分布式事件的处理方法，其特征在于，在从所述事件报文中提取得到事件数据这一步骤之后，所述方法包括：

对所述事件数据进行校验；

确定校验通过，根据所述事件数据生成所述标识信息。

5.一种分布式事件的处理方法，其特征在于，所述处理方法包括以下步骤：

根据预设协议构建第二通信连接；

通过所述第二通信连接向服务端发送订阅请求，以使服务端根据所述订阅请求返回目标订阅事件；

根据所述目标订阅事件进行业务逻辑处理；

其中，以使服务端根据所述订阅请求返回目标订阅事件这一步骤包括：

使服务端对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

使服务端建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；

使服务端通过回调处理函数的调用，以使所述逻辑关键词和所述候选订阅事件进行筛选匹配，并剔除匹配程度不满足预设阈值的候选订阅事件，得到目标订阅事件。

6.根据权利要求5所述的一种分布式事件的处理方法，其特征在于，在根据所述目标订阅事件进行业务逻辑处理这一步骤之后，所述处理方法还包括：

确定业务逻辑处理完成，生成服务响应信息；

将所述服务响应信息发送至所述服务端，以使所述服务端通过处理函数对订阅进行二次处理，对所述候选订阅事件进行更新；

获取从更新后的候选订阅事件中提取得到的目标订阅事件。

7.根据权利要求5所述的一种分布式事件的处理方法，其特征在于，所述处理方法包括以下步骤：

获取事件数据，将所述事件数据进行编码得到事件报文；

将所述事件报文发送至服务端，以使所述服务端将所述事件报文投递至目标节点；

接收所述服务端反馈事件报文投递完成后的标识信息；

其中，以使所述服务端将所述事件报文投递至目标节点的步骤包括：

使服务端从所述事件报文中提取得到事件数据；将所述事件数据进行编码得到第一结构消息；

使服务端从节点池中筛选得到存活的目标节点；

使服务端向所述目标节点投递所述第一结构消息。

8.一种分布式事件的处理系统，其特征在于，包括客户端和服务端；

所述服务端包括：

第一数据传输单元，用于获取客户端发送的订阅请求，和/或将目标订阅事件发送至客户端；

数据解码单元，用于对所述订阅请求进行解码，从解码后的所述订阅请求中提取得到逻辑关键词；

实时消息单元，用于建立与分布式实时消息平台的第一通信连接，根据所述逻辑关键词通过所述第一通信连接获取得到候选订阅事件；并通过回调处理函数对所述候选订阅事件进行筛选，得到目标订阅事件；

所述客户端包括：

第二数据传输单元，用于根据预设协议构建第二通信连接；并通过所述第二通信连接向服务端发送订阅请求；

事件处理单元，用于根据所述目标订阅事件进行业务逻辑处理。

9.一种分布式事件的处理设备，其特征在于，包括：

至少一个处理器；

至少一个存储器，用于存储至少一个程序；

当所述至少一个程序被所述至少一个处理器执行，使得所述至少一个处理器运行如权利要求1-7任一项所述的一种分布式事件的处理方法。

10.一种存储介质，其中存储有处理器可执行的程序，其特征在于，所述处理器可执行的程序在由处理器执行时用于运行如权利要求1-7中任一项所述的一种分布式事件的处理方法。