CN117654057A - 业务处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种业务处理方法、装置、设备及存储介质，该方法包括：获取业务处理请求消息；确定业务处理请求消息对应的第一类型业务以及第二类型业务，第一类型业务为可回滚业务；按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行；若第一存储节点返回存储成功的通知消息，则按照预设业务执行策略执行第二类型业务。采用本申请提供的方法，可以实现在提高业务并发性的同时，确保业务中数据的一致性。

Description

业务处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及业务处理方法、业务处理装置、业务处理设备及计算机可读存储介质。

背景技术

通常一个业务中包含多个子业务，例如在游戏场景下，对于玩家组队业务包含了多个子业务如下：写入玩家与团队的正向关系数据、写入团队与玩家的反向关系数据、向玩家发送入团成功通知、向玩家发送入团奖励等。

对于包含多个子业务的业务，现有技术一般采用弱一致性方案，先写入上述正向关系，再写入上述反向关系。但如果正向关系写入成功，但是反向关系由于网络问题失败，会导致存储记录用户加入了战队，但是战队成员列表查不到该用户，从而无法确保数据的一致性。另一种采用事务数据库的方案，由于本地事务的数据库中会使用全局锁等方案，从而造成业务的并发性能低下。对于包含多个业务的业务，如何即能保证并发性又能确保数据的一致性，成为了待解决的问题。

发明内容

本申请实施例提供了一种业务处理方法、装置、业务处理设备及存储介质，可以在提高业务并发性的同时，确保业务中数据的一致性。

第一方面，本申请实施例提供了一种业务处理方法，所述方法包括：

获取业务处理请求消息；确定所述业务处理请求消息对应的第一类型业务以及第二类型业务，所述第一类型业务为可回滚业务；按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，所述第一数据存储指令包括所述第一类型业务的业务数据，所述第一数据存储指令用于指示所述第一存储节点存储所述第一类型业务的业务数据，所述预设业务执行策略包括并发执行；若所述第一存储节点返回存储成功的通知消息，则按照所述预设业务执行策略执行所述第二类型业务。

第二方面，本申请实施例提供了一种业务处理方法，该方法包括：接收管理服务器按照预设业务执行策略发送的第一数据存储指令，所述第一数据存储指令包括第一类型业务的业务数据，所述第一类型业务的业务数据包括正向关系数据和反向关系数据，所述第一类型业务是基于业务处理请求消息确定的，所述第一类型业务为可回滚业务；响应所述第一数据存储指令，并发存储所述正向关系数据和所述反向关系数据；若所述第一类型业务的业务数据存储成功，则向所述管理服务器返回存储成功的通知消息，以使得所述管理服务器按照所述预设业务执行策略，执行基于所述业务处理请求消息确定的第二类型业务。

第三方面，本申请实施例提供了一种业务处理装置，该业务处理装置包括：获取单元，用于获取业务处理请求消息；处理单元，用于确定所述业务处理请求消息对应的第一类型业务以及第二类型业务，所述第一类型业务为可回滚业务；所述处理单元，还用于按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，所述第一数据存储指令包括所述第一类型业务的业务数据，所述第一数据存储指令用于指示所述第一存储节点存储所述第一类型业务的业务数据，所述预设业务执行策略包括并发执行；所述处理单元，还用于若所述第一存储节点返回存储成功的通知消息，则按照所述预设业务执行策略执行所述第二类型业务。

第四方面，本申请实施例提供了一种业务处理装置，该装置包括：获取单元，用于接收管理服务器按照预设业务执行策略发送的第一数据存储指令，所述第一数据存储指令包括第一类型业务的业务数据，所述第一类型业务的业务数据包括正向关系数据和反向关系数据，所述第一类型业务是基于业务处理请求消息确定的，所述第一类型业务为可回滚业务；处理单元，用于响应所述第一数据存储指令，并发存储所述正向关系数据和所述反向关系数据；所述处理单元，还用于若所述第一类型业务的业务数据存储成功，则向所述管理服务器返回存储成功的通知消息，以使得所述管理服务器按照所述预设业务执行策略，执行基于所述业务处理请求消息确定的第二类型业务。

第五方面，本申请实施例提供了一种计算机设备，该计算机设备包括：处理器、存储器以及网络接口；处理器与存储器、网络接口相连，其中，网络接口用于提供网络通信功能，存储器用于存储程序代码，处理器用于调用程序代码，以执行本申请实施例中的业务处理方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行本申请实施例中的业务处理方法。

第七方面，本申请实施例提供了一种计算机程序产品，所述计算机程序产品包括计算机程序或计算机指令，所述计算机程序或计算机指令被处理器执行时实现本申请实施例提供的业务处理方法的步骤。

本申请实施例首先管理服务器获取业务处理请求消息后，管理服务器确定业务处理请求消息对应的第一类型业务以及第二类型业务。再由管理服务器按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行。第一存储节点响应第一数据存储指令，并发存储正向关系数据和反向关系数据。管理服务器若第一存储节点返回存储成功的通知消息，则按照预设业务执行策略执行第二类型业务。从而实现在提高业务并发性的同时，确保业务中数据的一致性。

附图说明

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

图1是本申请实施例提供的一种系统架构示意图；

图2是本申请实施例提供的一种业务处理方法的应用场景示意图；

图3是本申请实施例提供的一种业务处理方法的流程示意图；

图4是本申请实施例提供的一种业包含多个业务的主业务示意图；

图5是本申请实施例提供的另一种业务处理方法的流程示意图；

图6是本申请实施例提供的又一种业务处理方法的流程示意图；

图7是本申请实施例提供的一种业务处理装置结构示意图；

图8是本申请实施例提供的一种业务处理设备结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了更好的理解本申请实施例，下面先对本申请实施例涉及的一些专业术语进行介绍：

幂等：是一个数学与计算机学概念，常见于抽象代数中。在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

回滚：指的是程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。回滚包括程序回滚和数据回滚等类型。

分布式事务：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

本申请实施例提供了一种业务处理方法，该业务处理方法涉及云技术(Cloudtechnology)，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

尤其涉及云技术中的云存储(Cloud storage)和数据库(Database)，云存储是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。数据库简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

该业务处理方法还涉及私有云(Private Cloud)，私有云是将云基础设施与软硬件资源创建在防火墙内，以供机构或企业内各部门共享数据中心内的资源。创建私有云，除了硬件资源外，一般还有云设备(IaaS，Infrastructure as a Service，基础设施即服务)软件。私有云计算同样包含云硬件、云平台、云服务三个层次。不同的是，云硬件是用户自己的个人电脑或服务器，而非云计算厂商的数据中心。云计算厂商构建数据中心的目的是为千百万用户提供公共云服务，因此需要拥有几十上百万台服务器。私有云计算，对个人来说只服务于亲朋好友，对企业来说只服务于本企业员工以及本企业的客户和供应商，因此个人或企业自己的个人电脑或服务器已经足够用来提供云服务。

在可行的实施例中，本申请实施例提供的业务处理方法可以基于云数据实现。具体可以涉及云数据中的云存储、私有云。

请参加图1，图1是本申请实施例提供的一种系统架构示意图。本申请实施例提供的业务处理方法可适用于图1所示的系统架构。如图1所示，图1中的101标记的设备为管理服务器101，102标记的设备为第一存储节点102，103为存储节点集群，该存储节点集群中可以包含多个存储节点，从该多个存储节点中选取一个存储节点作为第一存储节点102。104为发送业务处理请求的终端设备。

在一种可能的实施例中，终端设备104向管理服务器101发送业务处理请求，管理服务器101获取业务处理请求消息后，管理服务器101确定该业务处理请求消息对应的第一类型业务以及第二类型业务，然后管理服务器101向存储节点集群103中的第一存储节点102发送第一数据存储指令，第一存储节点102接收到该第一数据存储指令后，响应该第一数据存储指令，并发存储该第一数据存储指令中的正向关系数据和反向关系数据。当第一存储节点102存储成功时，向管理服务器101返回存储成功的通知消息。管理服务器101收到该第一存储节点102发送的存储成功通知消息后，按照预设业务执行策略执行第二类型业务。

可选的，管理服务器101可以是服务器或者客户端等计算设备，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。该管理服务器还可以是一个节点，但并不局限于此。

可选的，第一存储节点102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

可选的，终端设备104可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能语音交互设备、智能家电、智能医疗设备、车载终端等终端设备，但并不局限于此。

进一步地，图1中的管理服务器101或者第一存储节点102为节点时，涉及的功能包括：路由，路由是节点具有的基本功能，用于支持节点之间的通信。具体的，存储节点集群103中的各个存储节点之间可以相互通信，该通信方式可以通过各个节点的路由功能实现。该管理服务器101与存储节点集群103中的各个存储节点之间也可以相互通信，该通信方式可以通过各个节点的路由功能实现。

进一步地，存储节点集群103中的各个存储节点之间的数据是同步的，也就是说当第一存储节点102中的数据发生改变时，该存储节点集群103中其他节点的该数据也会发生改变，使得同样的数据在存储节点集群103的各个节点中是相同的。

本申请提供的业务处理方法可以应用于以下场景：玩家户游戏组队、商家扣除库存、团队积分消费等。需要说明的，上述场景仅为举例，本方案还可以应用于其他场景，在此不做赘述。

示例性的，结合图2对本申请提供的业务处理方法应用于玩家游戏组队的场景进行举例。如图2所示，图2所示的两个界面为玩家智能手机上游戏的组队画面。在该游戏中，玩家可以加入军团进行组队，在加入军团后玩家可以参与军团活动以获取奖励。玩家通过点击终端设备104界面上的加入按钮选择想要进入的军团，如玩家选择加入神秘军团-7，则点击加入按钮201，此时终端设备104向管理服务器101发送业务处理请求消息，管理服务器101获取到业务处理请求消息，该玩家加入军团的操作请求作为该业务请求消息对应的第一类型业务和第二类型业务。该第一业务包括：玩家可以看到自己所在的军团以及军团中的其他玩家可以看到该玩家加入后的信息(如图2中的玩家信息202)。管理服务器101按照预设业务执行策略向存储节点集群103的第一存储节点102发送第一数据存储指令，第一数据存储指令包括该玩家的信息以及该神秘军团-7的标识等。第一存储节点102并发存储该玩家与军团的正向关系数据(玩家可以看到自己加入的军团信息)以及反向关系数据(同一军团的其他玩家可以看到该玩家的信息)。当第一存储节点102存储成功后，向管理服务器101返回存储成功的消息，管理服务器101接收后该消息后，按照预设业务执行策略执行第二类型业务(通知该玩家成功加入神秘军团-7以及将入团奖励发送给该玩家)。

示例性的，对本申请提供的业务处理方法应用于商家扣除库存的场景进行举例。在用户进行购买时，玩家点击终端设备104界面上购买按钮后，终端设备104向管理服务器101发送业务处理请求消息，管理服务器101获取到该业务处理请求消息，该购买操作请求作为该业务请求消息对应的第一类型业务和第二类型业务。该第一业务包括：用户可以看到自己购买的商品以及其他用户可以看到该用户购买过该商品。管理服务器101按照预设业务执行策略向存储节点集群103的第一存储节点102发送第一数据存储指令，第一数据存储指令包括该用户的信息以及该商品的标识等。第一存储节点102并发存储该用户与商品的映射关系(用户可以看到自己购买的该商品)以及反向关系数据(其他用户可以看到该用户购买过该商品的信息)。当第一存储节点102存储成功后，向管理服务器101返回存储成功的消息，管理服务器101接收后该消息后，按照预设业务执行策略执行第二类型业务(通知该用户成功购买该商品，并将购买后的商家福利发放给该用户)。

下面结合图3对本申请实施例提供的业务处理方法进行详细说明。请参见图3，图3为本申请实施例提供的业务处理方法的流程示意图。本申请实施例提供的业务处理方法包括步骤S301～S307，如下：

S301、管理服务器获取业务处理请求消息。

其中，在玩家游戏组队场景下，业务处理请求消息包括玩家标识以及团队标识。其中，该玩家标识包括玩家的名称和玩家的账号等，该团队标识包括团队的名称和团队的编号等。在商家扣除库存的场景下，业务处理请求消息包括用户标识以及商品标识。其中，该用户标识包括用户的名称和用户的账号等，该商品标识包括商品的名称和商品的编号等。该业务处理请求消息可以是用户通过操作终端设备后，由终端设备发送给管理服务器的。

在一种可能的实施例中，用户通过操作终端设备发送业务处理请求消息后。管理设备接收该业务处理请求消息。

S302、管理服务器确定业务处理请求消息对应的第一类型业务以及第二类型业务，第一类型业务为可回滚业务。

在一种可能的实施例中，管理服务器确定出业务处理请求消息对应的业务中的可回滚业务；将该可回滚业务作为第一类型业务；确定出业务处理请求消息对应的业务中的不可回滚业务；将该不可回滚业务作为第二类型业务。

其中，将与用户相关的业务(如向用户发送通知和奖励)作为不可回滚业务，将与数据库相关的业务(如将用户信息存入数据库)作为可回滚业务。

示例性的，在玩家游戏组队场景下，如图4所示，图4中的主业务为业务处理请求对应的主业务400。该主业务400包括四个业务：存储正向关系数据(将用户与团队的映射关系存入数据库)、存储反向关系数据(将用户与团队的映射关系存入数据库)、向用户发送加入成功通知、向用户发放组队奖励。其中，将与数据库相关的业务(将用户与团队的映射关系存入数据库和将用户与团队的映射关系存入数据库)作为第一类型业务401；将用户相关的业务(向用户发送加入成功通知和向用户发放组队奖励)作为第二类型业务402。其中，用户与团队的正向关系可以理解为用户能够看到自己所加入的团队；团队与用户的反向关系可以理解为团队的人数在用户加入后会进行增加。

S303、管理服务器按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行。

其中，预设业务执行策略包括第一类型业务中的业务并发执行，第二类型业务中的业务并发执行。第一类型业务的业务数据包括用户的标识以及团队的标识，该用户标识和团队标识是管理服务器从终端设备发送的业务处理请求消息中获取的。

可选的，该存储节点集群可以是远程字典服务(Remote Dictionary Server，Redis)。为了更好的理解本申请提供的业务处理方法，下面对Redis做进一步的解释。Redis是一个键值对(key-value)存储系统，Redis的数据是存在内存中的，与传统数据库相比Redis读写速度更快。Redis具有高性能和高并发的特性。高性能：用户第一次访问该数据库中的数据后，将该访问的数据存在缓存中，下一次用户再次访问该访问的数据时，直接从换从中获取，当数据库中对应的数据发生改变时，自动同步改变缓存中的数据。高并发：由于把数据库中的部分数据转移到缓存中，用户可以直接从缓存中获取部分数据。

S304、第一存储节点接收管理服务器按照预设业务执行策略发送的第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一类型业务的业务数据包括正向关系数据和反向关系数据，第一类型业务的业务是基于业务处理请求消息确定的，第一类型业务为可回滚业务。

其中，第一类型业务和第一类型业务的业务数据可参见上述详细的解释。正向关系数据为用户—团队正向关系，也就是对于用户，该用户加入的团队。反向关系数据为团队—用户反向关系，也就是对于团队，该团队中包含的用户。

S305、第一存储节点响应第一数据存储指令，并发存储正向关系数据和反向关系数据。

其中，正向关系数据与反向关系数据的解释可参见上述。在存储该正向关系数据时，用户标识作为键值对中的键(key)，团队标识作为键值对中的值(value)；在存储该反向关系数据时，团队标识作为键值对中的value，此时团队标识对应的value可以是一个用户数组，用户该数组中存放有该加入该团队的用户的用户标识。下面分别对存储正向关系数据和存储反向关系数据分别进行介绍。

存储正向关系数据：将用户标识作为key，将团队标识作为value进行存储。当用户查看自己所在的团队时，通过在第一存储节点中查询该用户标识，从而确定出该用户标识对应的团队标识。将该团队标识对应的团队信息反馈给用户。

存储反向关系数据：将团队标识作为key，将用户标识存入该团队标识对应的用户数组。当团队中的任一用户查看所在团队中的人员列表时，通过在第一存储节点中查询该团队标识，从而确定出该团队标识对应的用户数组，进而确定出位于该团队中的其他用户标识。将其他用户标识对应的用户信息反馈给该用户。

在一种可能的实施例中，第一存储节点响应第一数据存储指令，并发存储正向关系数据和反向关系数据，包括：第一存储节点响应第一数据存储指令，获取业务处理请求消息的订单状态；若订单状态不存在，则第一存储节点并发存储正向关系数据和反向关系数据，并创建业务处理请求消息的订单状态，以及设置订单状态为第一状态。

其中，订单状态不存在代表该第一存储节点还未开始存储正向关系数据和反向关系数据。

在一种可能的实施例中，若订单状态存在，则第一存储节点拒绝存储正向关系数据和反向关系数据。

在一种可能的实施例中，订单状态存在包括三种状态：第一状态、第二状态以及第三状态。其中，该第一状态表示该第一存储节点已经将正向关系数据存储，或已经将反向关系存储，或已经将正向关系和反向关系存储。第二状态表示该第一存储节点已经执行回滚操作，该回滚操作在后续的描述中有详细解释，可以参见后续描述。第三状态表示该第一存储节点发生了空回滚，空回滚在后续的描述中又详细解释，可以参见后续描述。第一类型业务中的两个子业务(存储正向关系数据和存储反向关系数据)分别作为两个订单，每个订单分别对应三种状态。也就是说，存储正向关系数据这一订单对应第一状态、第二状态以及第三状态；存储反向关系数据这一订单同样对应第一状态、第二状态以及第三状态。为了方便描述，下面用Do表示存储操作。Undo表示回滚操作。

示例性的，在游戏组队的场景下，若订单不存在，则第一存储节点继续执行Do(第一存储节点存储用户团队映射关系和团队用户映射关系)，并对团队人数加1，记录订单状态为第一状态。

示例性的，在游戏组队的场景下，若订单状态为第一状态，则表示第一存储节点已经完成了该订单，不需要再次执行，第一存储节点返回成功消息给管理服务器。

示例性的，在游戏组队的场景下，若订单状态为第二状态，则表示Do操作在Undo之后达到，防悬挂(防悬挂在后续S508中进行了详细的解释)，第一存储节点不执行Do操作，并将防悬挂错误码返回给管理服务器。

示例性的，在游戏组队的场景下，若订单状态为第三状态，则表示发生了空回滚，此时第一存储节点不执行Do操作，并将空回滚错误返回给管理服务器。

通过根据订单的订单状态，判断是否需要执行存储操作，避免多次重复存储以及发生空回滚的情况，确保了存储数据的准确性和有效性。

S306、若第一类型业务的业务数据存储成功，则第一存储节点向管理服务器返回存储成功的通知消息，以使得管理服务器按照预设业务执行策略，执行基于业务处理请求消息确定的第二类型业务。

其中，第一类型业务的业务数据中的正向关系数据和反向关系数据均存储成功时，第一存储节点向管理服务器返回存储成功地通知消息。该返回存储的通知消息用于告知管理设备第一类型业务的业务数据已经成功存储在第一存储节点中。下面对第一类型业务的业务数据的存储进行举例说明。

S307、若第一存储节点返回存储成功的通知消息，则管理服务器按照预设业务执行策略执行第二类型业务。

其中，第二类型业务为不可回滚业务，可参见上述中对该不可回滚业务的解释。预设业务执行策略为并发执行，也就是说，为第二类型业务的业务均为并发执行的。第二类型业务需要在第一类型业务完成后才能执行。如图4所示，图4中的主业务为业务处理请求对应的主业务400。该主业务400包括第一类型业务401和第二类型业务402。第一类型业务401中包含的两个业务(存储正向关系数据和存储反向关系数据)并发执行，第二类型业务402中包含的两个业务(通知用户加入成功和发放入团奖励)并发执行，在完成第一类型业务之后，才能进行第二类型业务。

在一种可能的实施例中，管理服务器向消息队列中添加业务处理请求；若第一存储节点返回存储成功的通知消息，则管理服务器按照预设业务执行策略执行第二类型业务；从消息队列中删除业务处理请求消息。

其中，消息队列是在消息的传输过程中保存消息的容器，该当管理服务器向消息队列中添加业务处理请求后，该消息队列中保存用户标识以及团队标识。当该管理服务器接收到第一存储阶段返回的存储成功的通知消息后，将该消息队列中保存的用户标识和团队标识删除。

消息队列的存在，使得当第一存储节点发生意外，不再具备存储能力时，其他存储节点可以从消息队列中获取该业务处理请求，将第一存储节点为执行的存储操作继续执行。

在一种可能的实施例中，第二类型业务为不可回滚业务，第二类型业务包括结果通知子业务以及激励投放子业务，按照预设业务执行策略执行第二类型业务，包括：并发执行结果通知子业务以及激励投放子业务；若结果通知子业务以及激励投放子业务中的任一子业务执行失败，则按照幂等重试策略再次执行任一子业务，直到结果通知子业务以及激励投放子业务执行成功。

其中，结果通知子业务用于通知用户加入团队成功，激励投放子业务用于将入团奖励发放给用户。为了保证该第二类型业务的有效性，通过幂等重试策略，在任一子业务实现失败时，再次执行该失败的子业务，直至该子业务成功。幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等重试策略是指的重试后产生的影响均相同，也就是说，在任一子业务实现失败时，再次执行该失败的子业务，此时不会因为多次对子业务重试影响数据。例如，将入团奖励发放给用户实现失败时，此时需要再次向用户发放奖励，由于幂等重试策略，再次发放奖励时，该奖励的相关数据和用户的相关信息数据等不会发生改变。

示例性的，若并发执行结果通知子业务和激励投放子业务时，激励投放子业务执行失败，结果通知子业务执行成功，则再次执行失败的结果通知子业务。知道该结果通知子业务执行成功。

上述实施例详细描述了当第一存储节点存储成功时，管理服务器与第一存储节点对应的操作。通过上述实施例可以实现在提高业务并发性的同时，确保业务中数据的一致性。下面结合图5对第一存储节点存储失败时，管理服务器与第一存储节点对应的操作。

S501、获取业务处理请求消息。

请参见上述步骤S301中的详细描述，在此不做赘述。

S502、确定业务处理请求消息对应的第一类型业务以及第二类型业务，第一类型业务为可回滚业务。

请参见上述步骤S302中的描述，在此不做赘述。

S503、管理服务器按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行。

请参见上述步骤S303中的描述，在此不做赘述。

S504、第一存储节点接收管理服务器按照预设业务执行策略发送的第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一类型业务的业务数据包括正向关系数据和反向关系数据，第一类型业务的业务是基于业务处理请求消息确定的，第一类型业务为可回滚业务。

请参见上述步骤S304中的描述，在此不做赘述。

S505、第一存储节点响应第一数据存储指令，并发存储正向关系数据和反向关系数据。

请参见上述步骤S305中的描述，在此不做赘述。

S506、若所述第一类型业务的业务数据存储失败，则第一存储节点向所述管理服务器返回存储失败的通知消息。

在一种可能的实施例中，当第一类型业务的任一业务数据存储失败时，认作该第一类型业务的业务数据存储失败。例如，第一类型业务包括存储正向关系数据和存储反向关系数据，当正向关系数据存储失败时，该第一类型业务的业务数据存储失败，或者当反向关系数据存储失败时，该第一类型业务的业务数据存储失败，或者当正向关系数据和反向关系数据都存储失败时，该第一类型业务的业务数据存储失败。

其中，存储失败的通知消息用于通知管理服务器第一存储节点对第一类型业务的业务数据存储失败。

S507、若第一存储节点返回存储失败的通知消息，则管理服务器向第一存储节点发送业务回滚指令，业务回滚指令用于指示第一存储节点回滚已执行的数据存储操作。

示例性的，若第一存储节点已经存储将正向关系数据，则业务回滚指令用于指示第一存储节点将存储正向关系数据操作进行回滚；若第一存储节点已经存储将反向关系数据，则业务回滚指令用于指示第一存储节点将存储反向关系数据操作进行回滚；若第一存储节点已经存储将正向关系数据和反向关系数据，则业务回滚指令用于指示第一存储节点将存储反向关系数据操作进行回滚。

S508、第一存储节点基于业务回滚指令与预设的异常处理策略对第一类型业务的业务数据进行回滚操作，预设的异常处理策略包括防空回滚。

其中，针对正向关系数据的回滚操作包括：将存储在第一存储节点的正向关系数据删除；针对反向关系数据的回滚操作包括：将存储在第一存储节点的反向关系数据删除，并将团队的人数减少一个。为了方便描述存储操作与回滚操作，下面用Do操作代表存储操作，用Undo操作代表回滚操作。

示例性的，如图2所示，初始状态的神秘军团—7包括8个玩家，当Do操作中的反向关系数据存储完成后，此时的神秘军团—7包括9个玩家(玩家9为新加入的玩家)。当对该反向关系数据进行Undo操作时，不仅需要将该神秘军团—7与玩家9之间的映射关系删除，还需要将神秘军团—7的人数减1，回到初始状态的8个玩家。

其中，预设的异常处理策略主要用于防止由于网络异常等情况造成的异常。下面对几种常见的，由于网络异常造成的异常操作进行解释。空回滚：当并发存储正向关系数据和反向关系数据时，正向关系数据存储失败，此时由于第一存储节点接收到回滚指令，触发正向关系数据和反向关系数据的Undo，反向关系数据的Undo操作由于网络原因比反向关系数据的Do操作先达到第一存储节点。也就是说，由于网络原因，反向关系数据还没有存入时，就进行了回滚。例如，团队中初始有8个玩家，反向关系数据存储后该团队中有9个玩家，回滚操作后该团队又回到8个玩家，但是由于空回滚的发生，团队中初始有8个玩家，此时还未完成存储反向关系数据就已经回滚，此时回滚后的团队只剩下7个玩家。防悬挂：Do操作在Undo操作之后到达，然而本次操作已经被Undo了，此时需要防悬挂拒绝本次Do操作。

为了解决上述中的异常情况，在第一存储节点执行回滚策略时，需要给予预设的异常处理策略进行Undo。

在一种可能的实施例中，基于业务回滚指令与预设的异常处理策略对第一类型业务的业务数据进行回滚操作，包括：第一存储节点响应业务回滚指令，获取业务处理请求消息的订单状态；若订单状态为第一状态，则第一存储节点对第一类型业务的业务数据中存储成功的正向关系数据或者反向关系数据进行回滚操作，并将订单状态设置为第二状态。

在一种可能的实施例中，若订单状态不为第一状态，则第一存储节点拒绝对第一类型业务的业务数据进行回滚操作。

其中，订单状态在上述中有详细的解释，可以参见S305中对订单状态的解释，在此不做赘述。订单状态包括三种：第一状态、第二状态以及第三状态。第一类型业务中的两个子业务(存储正向关系数据和存储反向关系数据)分别作为两个订单，每个订单分别对应三种状态。也就是说，存储正向关系数据这一订单对应第一状态、第二状态以及第三状态；存储反向关系数据这一订单同样对应第一状态、第二状态以及第三状态。订单状态不为第一状态时，订单状态可以为第二状态或者第三状态。

示例性的，在游戏组队的场景下，在第一存储节点对正向关系数据或反向关系数据执行Undo时，若订单不存在或者订单状态为第三状态，则说明此时已经发生空回滚，第一存储节点记录此时的订单状态为第三状态，并将空回滚错误码返回给管理服务器。

示例性的，在游戏组队的场景下，在第一存储节点对正向关系数据或反向关系数据执行Undo时，若订单状态为第一状态，则说明可以进行Undo，Undo后第一存储节点对团队的人数进行减1，记录订单状态为第二状态。

示例性的，在游戏组队的场景下，在第一存储节点对正向关系数据或反向关系数据执行Undo时，若订单状态为第二状态，则说明已经Undo，返回成功通知。

在一种可能的实施例中，若订单状态不为第一状态，则第一存储节点拒绝对第一类型业务的业务数据进行回滚操作，具体为：若订单状态为第二状态，则第一存储节点拒绝对第一类型业务的业务数据进行回滚操作，并向管理服务器发送防悬挂错误信息，该防悬挂错误信息用于通知管理服务器在回滚时发生了防悬挂；若订单状态不存在或者订单状态为第三状态，则第一存储节点拒绝对第一类型业务的业务数据进行回滚操作，并向管理服务器发送空回滚错误信息，该空回滚错误信息用于通知管理服务器在回滚时发生了空回滚。

S509、第一存储节点向管理服务器发送业务回滚指令的响应消息，以使得管理服务器按照预设业务执行策略向存储节点集群的第二存储节点发送第二数据存储指令，第二数据存储指令用于指示第二存储节点存储业务处理请求消息对应的第一类型业务的业务数据。

请参见下述步骤S510中的描述，在此不做赘述。

S510、若第一存储节点返回业务回滚指令的响应消息，则管理服务器按照预设业务执行策略向存储节点集群的第二存储节点发送第二数据存储指令，第二数据存储指令用于指示第二存储节点从消息队列中获取业务处理请求消息，并存储业务处理请求消息对应的第一类型业务的业务数据。

其中，第二存储节点与第一存储节点位于同一的存储节点集群，也就是说第一存储节点和第二存储节点中的数据是同步的。当第一存储节点返回业务回滚指令的相应消息时，表面该第一存储节点已经回滚完成了，此时第二存储节点从消息队列中重新获取业务处理请求消息，并由第二存储节点将第一类型业务的业务数据存储。

为了更好的理解上述存储失败时的回滚流程，下面结合图6对该过程做进一步的解释。

示例性的，在游戏组队的场景下，请参见图6，接入层用于接收和发送请求，组队服务为管理服务器，Redis为存储节点集群，Kaflka为消息队列，601为第一类型业务，603为第二类型业务，602为失败时的操作流程。首先接入层获取到业务处理请求(可参见上述S301)，该接入层将业务处理请求中的信息投递给Kaflka消息队列进行缓存，该接入层将该组队请求(组队请求中包含用户标识和战队标识)发送给组队服务。组队服务接收到请求后，向Redis发送存储指令，Redis对用户-战队正向关系和战队-用户反向关系进行存储(可参见上述S303)。Redis对上述任一关系存储失败后，向组队服务发送失败通知(可参见上述S506)，组队服务接收该通知后向Redis发送回滚指令(可参见上述S507)，让Redis回滚上述存储操作后重新进行存储操作(可参见上述S508)。在Redis存储完成后，组队服务通知返回数据给接入层，通知用户已经成功加入战队，并将奖励发放给用户(可参见上述S307)。组队服务在成功完成存储后告知Kaflka删除数据的数据。

通过上述实施例可以实现在提高业务并发性的同时，确保业务中数据的一致性。

参见图7，图7是本申请实施例提供的业务处理装置的结构示意图。本申请实施例提供的数据处理装置包括：获取单元701、处理单元702。

获取单元701，用于获取业务处理请求消息；

处理单元702，用于按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行；

处理单元702，还用于若第一存储节点返回存储成功的通知消息，则按照预设业务执行策略执行第二类型业务。

在另一种实现中，处理单元702，还用于向消息队列中添加业务处理请求消息；

处理单元702，还用于若第一存储节点返回存储失败的通知消息，则向第一存储节点发送业务回滚指令，业务回滚指令用于指示第一存储节点回滚已执行的数据存储操作；

处理单元702，还用于若第一存储节点返回业务回滚指令的响应消息，则按照预设业务执行策略向存储节点集群的第二存储节点发送第二数据存储指令，第二数据存储指令用于指示第二存储节点从消息队列中获取业务处理请求消息，并存储业务处理请求消息对应的第一类型业务的业务数据。

在另一种实现中，处理单元702，还用于若第二存储节点返回存储成功的通知消息，则按照预设业务执行策略执行第二类型业务；

处理单元702，还用于从消息队列中删除业务处理请求消息。

在另一种实现中，处理单元702，还用于并发执行结果通知子业务以及激励投放子业务；

处理单元702，还用于若结果通知子业务以及激励投放子业务中的任一子业务执行失败，则按照幂等重试策略再次执行任一子业务，直到结果通知子业务以及激励投放子业务执行成功。

另一方面，本申请实施例提供的数据处理装置包括：获取单元701、处理单元702。

获取单元701，用于接收管理服务器按照预设业务执行策略发送的第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一类型业务的业务数据包括正向关系数据和反向关系数据，第一类型业务是基于业务处理请求消息确定的，第一类型业务为可回滚业务；

处理单元702，用于响应第一数据存储指令，并发存储正向关系数据和反向关系数据；

处理单元702，还用于若第一类型业务的业务数据存储成功，则向管理服务器返回存储成功的通知消息，以使得管理服务器按照预设业务执行策略，执行基于业务处理请求消息确定的第二类型业务。

在另一种实现中，处理单元702，还用于若第一类型业务的业务数据存储失败，则向管理服务器返回存储失败的通知消息；

获取单元701，还用于接收管理服务器基于存储失败的通知消息发送的业务回滚指令；

处理单元702，还用于基于业务回滚指令与预设的异常处理策略对第一类型业务的业务数据进行回滚操作，预设的异常处理策略包括防空回滚；

处理单元702，还用于向管理服务器发送业务回滚指令的响应消息，以使得管理服务器按照预设业务执行策略向存储节点集群的第二存储节点发送第二数据存储指令，第二数据存储指令用于指示第二存储节点存储业务处理请求消息对应的第一类型业务的业务数据。

在另一种实现中，处理单元702，还用于响应业务回滚指令，获取业务处理请求消息的订单状态；

处理单元702，还用于若订单状态为第一状态，则对第一类型业务的业务数据中存储成功的正向关系数据或者反向关系数据进行回滚操作，并将订单状态设置为第二状态。

在另一种实现中，处理单元702，还用于若所述订单状态不为所述第一状态，则拒绝对所述第一类型业务的业务数据进行回滚操作。

在另一种实现中，处理单元702，还用于响应第一数据存储指令，获取业务处理请求消息的订单状态；

处理单元702，还用于若订单状态不存在，则并发存储正向关系数据和反向关系数据，并创建业务处理请求消息的订单状态，以及设置订单状态为第一状态。

可以理解的是，本申请实施例提供的业务处理装置的各功能单元的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例中的相关描述，此处不再赘述。

在其它可行的实施例中，本申请实施例提供的业务处理装置也可以采用软硬件结合的方式实现，作为示例，本申请实施例提供的业务处理装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的业务处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application SpecificIntegrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件。

请参见图8，是本申请实施例提供的一种业务处理设备的结构示意图，该设备80可以包括处理器801、存储器802、网络接口803和至少一个通信总线804。其中，处理器801用于调度计算机程序，可以包括中央处理器、控制器、微处理器；存储器802用于存储计算机程序，可以包括高速随机存取存储器RAM，非易失性存储器，例如磁盘存储器件、闪存器件；网络接口803可选的可以包括标准的有线接口、无线接口(如WI-FI接口)，提供数据通信功能，通信总线804负责连接各个通信元件。存储器802用于存储计算机程序，该计算机程序包括程序指令，处理器801用于执行存储器802存储的程序指令，以执行上述实施例中步骤S301至步骤S307中描述的过程，执行如下操作：

在一种实现中，获取业务处理请求消息；确定业务处理请求消息对应的第一类型业务以及第二类型业务，第一类型业务为可回滚业务；按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一数据存储指令用于指示第一存储节点存储第一类型业务的业务数据，预设业务执行策略包括并发执行；若第一存储节点返回存储成功的通知消息，则按照预设业务执行策略执行第二类型业务。

本申请实施例还提供另一种业务处理设备，该设备执行如下：接收管理服务器按照预设业务执行策略发送的第一数据存储指令，第一数据存储指令包括第一类型业务的业务数据，第一类型业务的业务数据包括正向关系数据和反向关系数据，第一类型业务是基于业务处理请求消息确定的，第一类型业务为可回滚业务；响应第一数据存储指令，并发存储正向关系数据和反向关系数据；若第一类型业务的业务数据存储成功，则向管理服务器返回存储成功的通知消息，以使得管理服务器按照预设业务执行策略，执行基于业务处理请求消息确定的第二类型业务。

具体实现中，上述业务处理设备可通过其内置的各个功能模块执行如上述图3中各个步骤所提供的实现方式，具体可参见上述各个步骤所提供的实现方式，在此不再赘述。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序包括程序指令，该程序指令被处理器执行时实现图3中各个步骤所提供的业务处理方法，具体可参见上述各个步骤所提供的实现方式，在此不再赘述。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序或计算机指令，所述计算机程序或计算机指令被处理器执行时实现图3中各个步骤所提供的业务处理方法，具体可参见上述各个步骤所提供的实现方式，在此不再赘述。

上述计算机可读存储介质可以是前述任一实施例提供的推荐模型训练装置或者上述终端设备的内部存储单元，例如电子设备的硬盘或内存。该计算机可读存储介质也可以是该电子设备的外部存储设备，例如该电子设备上配备的插接式硬盘，智能存储卡(smart media card,SMC)，安全数字(secure digital,SD)卡，闪存卡(flash card)等。进一步地，该计算机可读存储介质还可以既包括该电子设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该电子设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

本申请的权利要求书和说明书及附图中的术语“第一”、“第二”、“第三”、“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请的具体实施方式中，涉及到用户信息(如用户标识等)相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置展示该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例提供的方法及相关装置是参照本申请实施例提供的方法流程图和/或结构示意图来描述的，具体可由计算机程序指令实现方法流程图和/或结构示意图的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。这些计算机程序指令可提供到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或结构示意图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或结构示意图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或结构示意一个方框或多个方框中指定的功能的步骤。

Claims (12)

1.一种业务处理方法，其特征在于，所述方法包括：

获取业务处理请求消息；

确定所述业务处理请求消息对应的第一类型业务以及第二类型业务，所述第一类型业务为可回滚业务；

按照预设业务执行策略向存储节点集群的第一存储节点发送第一数据存储指令，所述第一数据存储指令包括所述第一类型业务的业务数据，所述第一数据存储指令用于指示所述第一存储节点存储所述第一类型业务的业务数据，所述预设业务执行策略包括并发执行；

若所述第一存储节点返回存储成功的通知消息，则按照所述预设业务执行策略执行所述第二类型业务。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

向消息队列中添加所述业务处理请求消息；

若所述第一存储节点返回存储失败的通知消息，则向所述第一存储节点发送业务回滚指令，所述业务回滚指令用于指示所述第一存储节点回滚已执行的数据存储操作；

若所述第一存储节点返回所述业务回滚指令的响应消息，则按照所述预设业务执行策略向所述存储节点集群的第二存储节点发送第二数据存储指令，所述第二数据存储指令用于指示所述第二存储节点从所述消息队列中获取所述业务处理请求消息，并存储所述业务处理请求消息对应的第一类型业务的业务数据。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

若所述第二存储节点返回存储成功的通知消息，则按照所述预设业务执行策略执行所述第二类型业务；

从所述消息队列中删除所述业务处理请求消息。

4.根据权利要求1-3中任意一项所述的方法，其特征在于，所述第二类型业务为不可回滚业务，所述第二类型业务包括结果通知子业务以及激励投放子业务，所述按照所述预设业务执行策略执行所述第二类型业务，包括：

并发执行所述结果通知子业务以及所述激励投放子业务；

若所述结果通知子业务以及所述激励投放子业务中的任一子业务执行失败，则按照幂等重试策略再次执行所述任一子业务，直到所述结果通知子业务以及所述激励投放子业务执行成功。

5.一种业务处理方法，其特征在于，所述方法包括：

接收管理服务器按照预设业务执行策略发送的第一数据存储指令，所述第一数据存储指令包括第一类型业务的业务数据，所述第一类型业务的业务数据包括正向关系数据和反向关系数据，所述第一类型业务是基于业务处理请求消息确定的，所述第一类型业务为可回滚业务；

响应所述第一数据存储指令，并发存储所述正向关系数据和所述反向关系数据；

若所述第一类型业务的业务数据存储成功，则向所述管理服务器返回存储成功的通知消息，以使得所述管理服务器按照所述预设业务执行策略，执行基于所述业务处理请求消息确定的第二类型业务。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

若所述第一类型业务的业务数据存储失败，则向所述管理服务器返回存储失败的通知消息；

接收所述管理服务器基于所述存储失败的通知消息发送的业务回滚指令；

基于所述业务回滚指令与预设的异常处理策略对所述第一类型业务的业务数据进行回滚操作，所述预设的异常处理策略包括防空回滚；

向所述管理服务器发送所述业务回滚指令的响应消息，以使得所述管理服务器按照所述预设业务执行策略向存储节点集群的第二存储节点发送第二数据存储指令，所述第二数据存储指令用于指示所述第二存储节点存储所述业务处理请求消息对应的第一类型业务的业务数据。

7.根据权利要求6所述的方法，其特征在于，所述基于所述业务回滚指令与预设的异常处理策略对所述第一类型业务的业务数据进行回滚操作，包括：

响应所述业务回滚指令，获取所述业务处理请求消息的订单状态；

若所述订单状态为第一状态，则对所述第一类型业务的业务数据中存储成功的正向关系数据或者所述反向关系数据进行回滚操作，并将所述订单状态设置为第二状态。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

若所述订单状态不为所述第一状态，则拒绝对所述第一类型业务的业务数据进行回滚操作。

9.根据权利要求5-8中任意一项所述的方法，其特征在于，所述响应所述第一数据存储指令，并发存储所述正向关系数据和所述反向关系数据，包括：

响应所述第一数据存储指令，获取所述业务处理请求消息的订单状态；

若所述订单状态不存在，则并发存储所述正向关系数据和所述反向关系数据，并创建所述业务处理请求消息的订单状态，以及设置所述订单状态为第一状态。

10.一种业务处理装置，其特征在于，包括用于执行如权利要求1-4中任一项所述方法的单元，或包括用于执行如权利要求5-9中任意一项所述方法的单元。

11.一种业务处理设备，其特征在于，包括：处理器、通信接口和存储器，所述处理器、所述通信接口和所述存储器相互连接，其中，所述存储器存储有可执行程序代码，所述处理器用于调用所述可执行程序代码，执行如权利要求1-4中任一项所述的业务处理方法，或执行如权利要求5-9中任一项所述的业务处理方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1-4中任一项所述的业务处理方法，或执行如权利要求5-9中任一项所述的业务处理方法。