CN110457141A

CN110457141A - 一种业务消息的处理方法、系统、装置及设备

Info

Publication number: CN110457141A
Application number: CN201910607509.5A
Authority: CN
Inventors: 刘启明
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-07-04
Filing date: 2019-07-04
Publication date: 2019-11-15
Anticipated expiration: 2039-07-04
Also published as: CN110457141B

Abstract

公开了一种业务消息的处理方法、系统、装置及设备。通过消息队列的形式在各子节点进行业务消息的订阅和发布，各子节点再将订阅到的业务消息转发营销端进行确认，从而错开了兑奖时间附近的消息高峰期，实现了对于业务消息的分流处理，避免了业务消息的高并发形成的网络异常造成的数据不一致。

Description

一种业务消息的处理方法、系统、装置及设备

技术领域

本说明书实施例涉及信息技术领域，尤其涉及一种业务消息的处理方法、系统、装置及设备。

背景技术

在当前，经常会出现一种以兑奖为机制的营销方式。具体而言，用户通过参与营销活动，在业务系统所提供的营销活动中进行答题、集卡、消费、分享等等行为，产生于该营销活动有关的历史交易数据，最终用户可以获得某种奖励，进而在一个兑奖时间点之后对所有用户集中兑奖。

在这种营销方式下，兑奖时间点附近，业务系统会面临用户的大量的高并发查询请求或者兑奖请求，容易造成网络的抖动与异常。而与此同时，由于业务端所确定的兑奖结果需要得到营销端的确认，否则，将会发生业务端与营销端的兑奖数据不一致，给用户造成困扰。

基于此，需要一种可以保证数据一致性的处理业务消息的方案。

发明内容

本申请实施例的目的是提供一种在兑奖方案中可以保证数据一致性的业务消息的处理案。

为解决上述技术问题，本申请实施例是这样实现的：

一种业务消息的处理方法，应用于包括业务端、营销端和消息中间件的系统中，其中，所述业务端包括多个分布式的子节点，所述方法包括：

业务端中的任一子节点，生成用于确定用户兑奖的业务消息，发布所述业务消息至消息中间件中，其中，所述业务消息包含业务标识和用户标识，所述业务消息以业务标识为主题；

消息中间件，将业务消息推送至订阅了该主题的子节点；

任一接收到消息中间件所推送的业务消息的子节点，转发接收到的业务消息至营销端；

营销端，确定接收到的业务消息中的用户标识所对应的用户的兑奖结果，并存储，发送包含所述兑奖结果的处理信息至业务端；

业务端，接收包含所述兑奖结果的处理信息，并存储所述兑奖结果。

对应的，本说明书实施例还提供一种业务消息的处理系统，包括业务端、营销端和消息中间件，其中，所述业务端包括多个分布式的子节点，在所述系统中，

消息中间件，将业务消息推送至订阅了该主题的子节点；

另一方面，本说明书实施例还提供一种业务消息的处理方法，应用于分布式的业务端中的子节点中，所述方法包括：

生成用于确定用户兑奖的业务消息，其中，所述业务消息包含业务标识和用户标识，所述业务消息以业务标识为主题；

发布所述业务消息至消息中间件中；

接收所述消息中间件中所推送以所述业务标识为主题的业务消息；

转发接收到的业务消息至营销端。

与另一方面对应的，本说明书实施例还提供一种业务消息的处理装置，应用于分布式的业务端中的子节点中，所述装置包括：

生成模块，生成用于确定用户兑奖的业务消息，其中，所述业务消息包含业务标识和用户标识，所述业务消息以业务标识为主题；

发布模块，发布所述业务消息至消息中间件中；

接收模块，接收所述消息中间件中所推送以所述业务标识为主题的业务消息；

发送模块，转发接收到的业务消息至营销端。

通过消息队列的形式在各子节点进行业务消息的订阅和发布，各子节点再将订阅到的业务消息转发营销端进行确认，从而错开了兑奖时间附近的消息高峰期，实现了对于业务消息的分流处理，在系统中从根本上避免了业务消息的高并发形成的网络异常造成的数据不一致，提高了系统的稳定性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为当前技术中所涉及的系统架构示意图；

图2为本说明书实施例所提供的系统架构示意图；

图3是本说明书实施例提供的一种业务消息的处理方法的流程示意图；

图4为本说明书实施例提供的一种业务消息的处理方法的流程示意图；

图5是本说明书实施例提供的一种业务消息的处理装置的结构示意图；

图6是用于配置本说明书实施例方法的一种设备的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。

在营销活动，一般的方式为营销端设计好各类营销活动，交由业务端进行执行。由此业务端产生相应的兑奖结果，并由营销端进行进一步的确认。在这个过程中，业务端一般是一种分布式的架构，包括多个子节点。各子节点分别面对用户以及营销端，如图1所示，图1为当前技术中所涉及的系统架构示意图。在这种架构下，各子节点本地需要存储有相应的用户数据，并且根据用户数据产生出兑奖结果，而营销端则可以对业务端所产生的兑奖结果进行确认或者调整。这个过程中，需要营销端和业务端的数据保持一致性。

而在具有兑奖时间点的这类营销活动中，往往则会在兑奖时间点前后，用户集中发起请求，导致各子节点同时向营销端请求确认，形成高并发事件导致网络异常或者延迟，造成营销端的数据和业务端的数据不一致。

基于此，本说明书实施例提供一种方案，从解决高并发所带来的网络消息传输问题。如图2所示，图2为本说明书实施例所提供的系统架构示意图。在该示意图中，业务端中的子节点和消息中间件已经存在了订阅/发布的关系。子节点中的消息被发布到消息中间件中的某个主题类别中，作为订阅者的子节点将收到其订阅的主题上的消息。容易理解，一个子节点所发布的消息不一定是其所订阅得到的消息。

以下结合附图，详细说明本说明书各实施例提供的技术方案。如图3所示，图3是本说明书实施例提供的一种业务消息的处理方法的流程示意图，应用于包括业务端、营销端和消息中间件的系统中，该流程具体包括如下步骤：

S301，业务端中的任一子节点，生成用于确定用户兑奖的业务消息，发布所述业务消息至消息中间件中。

在营销活动中，用户可以向业务端中的任一子节点进行查询或者确认。从而，任一接收到用户请求的子节点，均可以在本地进行相应的计算，确认该用户的中奖情形。

具体而言，可以在业务端数据库中查询获取用户在本次营销活动中的历史交易数据，其中的历史交易数据包括答题、集卡、消费、分享等等行为；或者，在营销活动需要跨平台时，业务端也可以向其它平台系统调用与本次营销活动相关的用户数据，例如，在电子商务平台中的用户交易数据。进而，可以根据用户历史交易数据确定出用户的中奖情形。

如果没有中奖，则不用生成业务消息。如果确认用户已经中奖，则确定出包含中奖情形的业务消息。业务端所确定的中奖情形可以包含中奖等级、奖品、有效领取时间等等。但是需要说明的是，业务端所确定用户中奖情形往往并不是最终结果，而只是一个初步结果，需要营销端进行最终的确认。

生成的业务消息中应当包含有业务标识和用户，业务标识用于标识该业务消息所归属的营销活动。例如，业务标识可以是“双11”，或者，“618”，或者，一个内部编号“001”等等。用户标识可以包括用户登录客户端时的用户名、手机号、身份证等等。

需要说明的是，在本说明书实施例中，业务端中的子节点和消息中间件已经存在了发布/订阅的关系。

在发布/订阅模型中，消息的发送者(发布者)不会将消息直接发送给特定的接收者(订阅者)，而是可以将发布的消息根据主题分为不同的类别进行发布，无需了解哪些订阅者可能存在。同样的，订阅者可以表达对一个或多个主题的兴趣，只接收已经订阅的主题所确定的类别消息，无需了解哪些发布者存在。一个子节点可以同时既是发布者也是订阅者。

订阅/发布的消息中的主题即为业务标识。从而，每当任一子节点生成了以该业务标识为主题的业务消息后，都可以将业务消息发布至消息中间件中。

S303，消息中间件，将业务消息推送至订阅了该主题的子节点

消息中间件对于接收到的业务消息即可以放进相应的以业务标识为主题的消息队列中进行发布。

在本说明书实施例中，一个子节点可以同时既是发布者，也是订阅者，此时，任一作为订阅的子节点将会收到业务消息；当然，也可以任一子节点都是发布者，但是只有部分子节点是订阅者，在这种情形下，没有订阅该主题的子节点将不会收到业务消息。

在一种实施例中，可以挑选少量部分业务量少的节点作为订阅者即可，在这种方式下，一方面可以降低业务消息向多个子节点重复发送的开销，另一方面，可以有效利用空闲的子节点。

在一种实施例中，消息中间件可以对消息队列长度进行限制，例如，每次只推送固定长度的队列至订阅子节点。

S305，任一接收到消息中间件所推送的业务消息的子节点，转发接收到的业务消息至营销端。

作为订阅方的子节点，将会接收到消息队列中所推送以业务标识为主题的业务消息。

需要说明的是，每个子节点对于接收到的业务消息的转发方式可以更为灵活，可以选择收到消息时就转发，可以选择定时转发，也可以划分时间段按不同转发速度进行处理等等。

S307，营销端，确定接收到的业务消息中的用户标识所对应的用户的兑奖结果，并存储，发送包含所述兑奖结果的处理信息至业务端。

容易理解，营销端此时仍然可以接到所有的业务消息。但是通过前述的消息中间件进行限流，错开了兑奖时间的高峰期，避免了高并发的同时进行。

在实际应用中，营销端同时对应的通常不仅仅是一个营销活动，在接收到业务消息时，首先可以根据业务标识确定是哪个营销活动，从而可以确定出在该营销活动中还有多少可兑现的奖品。

如前所述，业务端基于用户历史数据已经计算得到用户的兑奖结果，并将结果包含于业务消息中，营销端需要对该结果进行确认即可。在一般情形下，营销端直接认可业务端所确认的兑奖结果即可。

在一种实施例中，由于各子节点在计算兑奖结果时是基于各子节点本地的数据库时，有可能发生兑奖结果在各子节点是合法的，但是最终在营销端中超过限额。例如，业务端和营销端共同协议了一等奖10名，在营销端由于各子节点之间的网络延迟，共同得到一等奖15名，从而超出了营销端的预计。

在一种实施例中，当业务端确用户的中奖情形是通过兑奖等级来表征时，如前所示，业务端可以根据用户的历史交易数据确定用户的第一兑奖等级，若在营销端，第一兑奖等级的用户没有超过预设的数量时，可以直接确定为第一兑奖等级确定为该用户(即业务消息中的用户标识所对应的用户)的兑奖结果；或者，当第一兑奖等级的用户数量已经到达阈值时，则在营销端中对于第一兑奖等级进行向下调整，降低为第二兑奖等级，例如，在上述示例中，即可以将后接收到的5条业务消息中的用户的兑奖等级调整为二等奖。

营销端在对业务消息进行处理后，可以确认为用户的兑奖结果，此时可以将用户的兑奖结果进行存储，并发送包含所述兑奖结果的处理信息至业务端。

S307，业务端，接收包含所述兑奖结果的处理信息，并存储所述兑奖结果。

通过前述方式，业务端所存储的结果即为营销端中的已经确认的结果，和营销端中的兑奖结果保持了一致。

但是在实际应用中，虽然通过消息中间件对于流量高峰进行了错开处理，分流到各子节点进行，但是仍然有可能因为多方面问题造成消息处理的不及时或者出错，例如，营销端的服务器发生物理异常，或者，营销端和业务端之间的网络发生了物理异常，或者，消息处理到中途抛出数据异常等等。

在这种实施方式下，业务端可以确定自身所发送的业务消息的已经失败。具体而言，可以是营销端返回处理失败的信息，或者，营销端返回反馈信息超时等等。从而，业务端可以将处理失败的消息重新返回至消息中间件中。消息中间件则将处理失败的业务消息加入消息重试队列，重新推送消息重试队列中的消息至子节点。消息重试队列的主题仍是前述的业务标识。通过对处理失败的消息进行重试，确保了业务端所发送的业务消息一定可以被营销端所收到并进行确认，从而可以保证在网络延迟和不稳定的情况下，实现营销端和业务端的数据最终一致性，避免兑奖结果在两个系统中的不一致给用户带来困扰。

在一种实施方式中，由于可能有多个子节点订阅了以该业务标识为主题的消息队列，而每个子节点均会接收到该消息队列中的消息，从而有可能发生有多个不同的子节点向营销端发送相同的业务消息。

为了避免营销端进行重复处理，可以预先建立索引表。该索引表中包含有业务标识和用户标识，每个用户标识有一个状态值，从而记录了每个用户的兑奖状态。

具体而言，营销端每接收到一条业务消息，即可以根据业务消息中的业务标识确定一份对应的索引表(即，各营销活动有各自的状态索引表)。进而查询索引表中是否存在业务消息中所包含的用户标识，如果存在，则查询用户标识的状态值，如果状态值为表征已经兑奖的表征值，不处理所述接收到的业务消息。

如果索引表中不存在业务消息中所包含的用户标识，则说明是首次处理该用户的兑奖信息，则此时可以处理该兑奖信息，并且，在兑奖信息处理完之后将用户标识和该用户的兑奖状态值建立对应关系，写入该索引。

需要说明的是，在本说明书实施例中，业务端是已经确定用户中奖，才发送包含用户标识的兑奖信息。因此，索引表中不会存在用户标识的状态值为未兑奖的表征值。

因此，在一种实施例中，索引表中还可以不包含用户标识的状态值，而是仅写入已经兑奖的用户标识即可，在这种实施方式下，用户标识写入该索引就可以表征该用户已经兑奖。进而，在接收到业务消息后，若查询索引表中已经存在业务消息中所包含的用户标识，则可以不对该业务消息进行处理。通过建立索引对用户兑奖状态进行记载，可以避免对于同一用户的兑奖信息进行重复处理，降低营销端的无效处理，提高效率。

在当前技术中，由于业务端在接收到用户的查询请求后，需要向用户返回查询结果。在如图1中所示的架构中，需要等待营销端对业务消息进行确认才能返回结果。

在本说明书的一种实施例中，由于通过消息中间件可以保证每个业务消息一定会得到营销端的处理，因此每个子节点则可以在向消息中间件发送业务消息的之后，即可返回包含兑奖成功(不一定包含兑奖等级，因为营销端可能会进行调整)的确认消息至所述用户标识所对应的客户端，降低了用户对于反馈消息的等待时长，提高了用户体验。

消息中间件，将业务消息推送至订阅了该主题的子节点；

进一步地，在所述系统中，在转发接收到的业务消息至营销端之后，任一子节点，若确定营销端对于自身所发送的业务消息处理失败，发送所述业务消息至消息中间件；相应的，消息中间件，将所述处理失败的业务消息加入消息重试队列，重新推送消息重试队列中的消息至子节点。

进一步地，在所述系统中，在所述系统中，任一子节点，查询获取用户的历史交易数据，根据所述历史交易数据确定用户的第一兑奖等级，生成包含所述第一兑奖等级的业务消息。

进一步地，在所述系统中，营销端，将所述第一兑奖等级确定为所述用户标识所对应的用户的兑奖结果。

进一步地，在所述系统中，营销端，若确定第一兑奖等级的用户数量已经到达阈值，将该用户标识所对应的用户的兑奖等级向下调整为第二兑奖等级。

进一步地，在所述系统中，营销端，在确定接收到的业务消息中的用户标识所对应的用户的兑奖结果之前，确定接收的业务消息中的业务标识和用户标识；确定所述业务标识所对应的预先建立的索引表，从该索引表中查询所述用户标识的状态值，若状态值为表征已经兑奖的表征值，不处理所述接收到的业务消息。

进一步地，在所述系统中，任一子节点，发布所述业务消息至消息中间件中之后，发送包含兑奖成功的确认消息至所述用户标识所对应的客户端。

对应的，本说明书实施例还提供一种业务消息的处理方法，应用于分布式的业务端中的子节点中，如图4所示，图4为本说明书实施例所提供的一种业务消息的处理方法的流程示意图，所述方法包括：

S401，生成用于确定用户兑奖的业务消息，其中，所述业务消息包含业务标识和用户标识，所述业务消息以业务标识为主题；

S403，发布所述业务消息至消息中间件中；

S405，接收所述消息中间件中所推送以所述业务标识为主题的业务消息；

S405，转发接收到的业务消息至营销端。

对应的，本说明书实施例还提供一种业务消息的处理装置，如图5所示，图5是本说明书实施例提供的一种业务消息的处理装置的结构示意图，包括：

生成模块501，生成用于确定用户兑奖的业务消息，其中，所述业务消息包含业务标识和用户标识，所述业务消息以业务标识为主题；

发布模块503，发布所述业务消息至消息中间件中；

接收模块505，接收所述消息中间件中所推送以所述业务标识为主题的业务消息；

发送模块507，转发接收到的业务消息至营销端。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图4所示的业务消息的处理方法。

图6示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图4所示的业务消息的处理方法。

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

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

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims

1.一种业务消息的处理方法，应用于包括业务端、营销端和消息中间件的系统中，其中，所述业务端包括多个分布式的子节点，所述方法包括：

消息中间件，将业务消息推送至订阅了该主题的子节点；

2.如权利要求1所述的方法，任一子节点，在转发接收到的业务消息至营销端之后，还包括：

任一子节点，若确定营销端对于自身所发送的业务消息处理失败，发送所述业务消息至消息中间件；

消息中间件，将所述处理失败的业务消息加入消息重试队列，重新推送消息重试队列中的消息至子节点。

3.如权利要求1所述的方法，任一子节点，生成用于确定用户兑奖的业务消息，包括：

任一子节点，查询获取用户的历史交易数据，根据所述历史交易数据确定用户的第一兑奖等级，生成包含所述第一兑奖等级的业务消息。

4.如权利要求3所述的方法，确定接收到的业务消息中的用户标识所对应的用户的兑奖结果，包括：

将所述第一兑奖等级确定为所述用户标识所对应的用户的兑奖结果。

5.如权利要求3所述的方法，营销端，确定业务消息中的用户标识所对应的用户的兑奖等级，包括：

若确定第一兑奖等级的用户数量已经到达阈值，将该用户标识所对应的用户的兑奖等级向下调整为第二兑奖等级。

6.如权利要求1所述的方法，营销端，在确定接收到的业务消息中的用户标识所对应的用户的兑奖结果之前，所述方法还包括：

营销端，确定接收的业务消息中的业务标识和用户标识；

确定所述业务标识所对应的预先建立的索引表，从该索引表中查询所述用户标识的状态值，若状态值为表征已经兑奖的表征值，不处理所述接收到的业务消息。

7.权利要求1所述的方法，任一子节点，发布所述业务消息至消息中间件中之后，所述方法还包括：

发送包含兑奖成功的确认消息至所述用户标识所对应的客户端。

8.一种业务消息的处理系统，包括业务端、营销端和消息中间件，其中，所述业务端包括多个分布式的子节点，在所述系统中，

消息中间件，将业务消息推送至订阅了该主题的子节点；

9.如权利要求8所述的系统，在所述系统中，在转发接收到的业务消息至营销端之后，

相应的，消息中间件，将所述处理失败的业务消息加入消息重试队列，重新推送消息重试队列中的消息至子节点。

10.如权利要求8所述的系统，在所述系统中，

11.如权利要求10所述的系统，在所述系统中，

营销端，将所述第一兑奖等级确定为所述用户标识所对应的用户的兑奖结果。

12.如权利要求10所述的系统，在所述系统中，

营销端，若确定第一兑奖等级的用户数量已经到达阈值，将该用户标识所对应的用户的兑奖等级向下调整为第二兑奖等级。

13.如权利要求8所述的系统，在所述系统中，营销端，在确定接收到的业务消息中的用户标识所对应的用户的兑奖结果之前，

确定接收的业务消息中的业务标识和用户标识；

14.如权利要求8所述的系统，在所述系统中，

任一子节点，发布所述业务消息至消息中间件中之后，发送包含兑奖成功的确认消息至所述用户标识所对应的客户端。

15.一种业务消息的处理方法，应用于分布式的业务端中的子节点中，所述方法包括：

发布所述业务消息至消息中间件中；

转发接收到的业务消息至营销端。

16.一种业务消息的处理装置，应用于分布式的业务端中的子节点中，所述装置包括：

发布模块，发布所述业务消息至消息中间件中；

发送模块，转发接收到的业务消息至营销端。

17.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求15所述的方法。