CN103310334B - 一种业务处理的方法及装置 - Google Patents

Abstract

本申请公开了一种业务处理的方法及装置，所述业务处理方法，应用在用于对数据进行处理的系统中，所述方法包括：获得第一业务；执行为所述第一业务设置对应的第一标识信息的操作；判断是否成功设置了所述第一标识信息；在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行。

Description

一种业务处理的方法及装置

技术领域

本申请涉及数据处理领域，尤其涉及一种业务处理方法及装置。

背景技术

业务幂等性包括两层含义：(1)同一业务不能重复做成功，比如，在付款时，不能重复付款；(2)业务规则互斥的业务不能同时成功，比如，在某一时刻，用户点击了付款，但是钱从用户的账户上转出后，并未显示付款成功，所以系统会有一个退款过程，那么这个付款和退款过程不能同时成功。

在现有技术中，常用的保持业务幂等性的方法，主要有下面两种：

(1)将所有的数据处理过程都利用数据库完成，利用数据库的事务特性来控制并发及互斥业务的执行，使其不能同时成功。

(2)开发分布式事务控制框架，并且，对于非事务性的缓存重写事务注册器，从而使得非事务性的缓存带有事务性的特点，进而使其能够达到与第(1)种方案控制业务幂等性相同的技术效果。

然而，在实现本申请实施例的过程中，申请人发现现有技术至少存在如下缺点：

(1)关于现有技术(1)，由于所有的数据都采用数据库进行储存，但是，对于海量数据的高并发、高效率存储与访问以及高扩展、高可靠性的处理要求，都是关系数据库难以达到的，故而存在着对于海量数据处理过程无法实现幂等性的技术问题；

(2)关于现有技术(2)，由于需要开发分布式系统框架，故而存在着技术难度大、开发成本高并且会增加业务复杂性的技术问题。

发明内容

本申请提供一种业务处理的方法及装置，用以解决现有技术中存在的实现业务幂等性的过程技术难度大技术问题。

本申请通过本申请中的实施例，提供如下技术方案：

一方面，本申请通过本申请中的一个实施例，提供如下技术方案：

一种业务处理的方法，应用在用于对数据进行处理的系统中，所述方法包括：

获得第一业务；

执行为所述第一业务设置对应的第一标识信息的操作；

判断是否成功设置了所述第一标识信息；

在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行。

另一方面，本申请通过本申请的另一实施例，提供如下技术方案：

一种业务处理的装置，应用在用于对数据进行处理的系统中，所述装置包括：

获得单元：用于获得第一业务；

设置单元：用于执行为所述第一业务设置对应的第一标识信息的操作；

判断单元：用于判断是否成功设置了所述第一标识信息；

执行单元：用于在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行。

本申请提供的一个或多个技术方案，至少具有如下技术效果或优点：

本申请实施例在获得第一业务后，由于先执行为所述第一业务设置对应的第一标识信息的操作；然后判断是否成功设置了所述第一标识信息；在成功设置了所述第一标识信息时，才执行所述第一业务；所以，保证在系统中已经存在与所述第一业务关系为相同或互斥的第二业务时，第一业务不会被执行，进而有效的达到了采用较为简便的方式即可实现关系为相同或互斥的业务幂等性的技术效果。

附图说明

图1为本申请实施例一中一种业务处理方法的步骤示意图；

图2为本申请实施例二中同一商品的多次付款业务并发执行的处理步骤示意图；

图3为本申请实施例三中服务器对于同一产品的付款业务和付款失败资金退回业务并发执行时的处理流程图；

图4为本申请实施例四中一种业务处理的装置的方框图。

具体实施方式

为实现本申请目的，本申请实施例提出一种业务处理的方法和装置，所述方法包括：在执行第一业务前，先给所述第一业务设置一对应的第一标识信息，如果能够成功设置第一标识信息，表明系统中没有与所述第一业务关系为相同或互斥的业务正在被执行，故而可以执行第一业务，而如果不能成功设置第一标识信息，那么说明系统中存在与所述第一业务关系为相同或互斥的第二业务正在被执行，故而，也就暂停执行第一业务。由于，这里只需要将第一业务对应的标识信息插入一数据库中的公共信息表，而对于被处理的数据，不需要数据库来存储，也不用开发分布式数据库框架，使非事务性的缓存带有事务性，就能实现第一业务的幂等性的技术效果，有效克服了现有技术中对于保持业务幂等性所采用的技术方案要么对于大批量的数据没法实现、要么实现较为复杂的技术问题。

下面结合说明书附图对本申请实施例的方案进行详细描述。

实施例一

本申请实施例应用在一数据处理的系统中，所述系统包含客户端、网络购物平台和服务器，本申请中的业务处理主要是基于服务器对客户端发送至网络购物平台的业务进行处理。

如图1所示，其为本申请实施例一中一种业务处理的方法步骤示意图，所述方法包括如下步骤：

S101：获得第一业务；

在具体实施过程中，所述第一业务可以是付款业务、付款失败资金退回业务、修改资费业务等。

比如，客户端A需要购买B产品，先通过账号和密码的方式登录到网络购物平台，在确定购买商品B时，便选择网银付款或者支付宝付款的方式进行付款，进行客户端会产生一付款请求，服务端接收到所述付款请求时，进而产生一个与所述付款请求对应的网银付款业务。

而客户端A在发出所述付款请求后，可能钱从网银或支付宝上汇出了，但是因为系统故障，或是其他原因，并未产生对应的付款成功标记，这必然导致BUG，故而服务器会对应的产生一个付款失败资金退回业务。

在客户端A购买B产品后，可能向客户端B，也就是B产品的店主提出修改资费，在协商成功后，客户端B会向服务器提出一个修改资费请求，进而，服务器产生一个修改资费业务。

业务幂等性指的就是第一业务或者是与第一业务互斥的业务只能成功一次。

例如，用户通过网络购物平台的支付宝提供的支付工具(比如网银、信用卡等)做支付业务，会做两个动作：(1)充值：也就是服务器将网银的钱充值到交易买家的支付宝账户中；(2)付款：也就是服务器将充值的钱转账给卖家的支付宝账户。对用户而言只有一个付款动作，但是支付宝内部实际上是充值+支付两个动作，当用户充值成功，但是付款失败的情况下，服务器需要将钱退回到用户的银行卡，这里边就需要控制一个逻辑用户的付款动作与充退动作不能同时成功——付款成功钱会打给卖家、充退成功钱会退给买家，如果同时成功，用户就会在不付钱的情况下将东西买到手，而实际付款的人会是公用的资金池，即可能是用用户A的钱来给用户B付了款。

故而在服务器获得第一业务后，会基于如下几种情况，来判断是否执行第一业务。

(1)在所述数据处理系统内，已经有与第一业务相同或互斥的业务执行成功。在所述数据处理系统中，每一业务执行成功，服务器都会于一数据表中写下一执行成功的标识信息，该信息为永久标识信息，并且处于服务器可知状态，故而只要于该数据表中查看是否存在与第一业务对应的执行成功的标识信息，即可得知是否有与第一业务相同或互斥的第二业务执行成功了。如果有与第一业务相同或互斥的第二业务执行成功，那么删除所述第一业务。比如，如果第一业务是对商品B付款业务，如果在所述数据表中已经有商品B的执行成功的标志信息，也就是商品B的付款业务已经执行成功，自然不用再次执行付款业务，故而删除付款业务；或者，如果在所述数据表中已经有商品B的付款失败资金回退业务执行成功的标志信息，表示付款并未成功，故而为了防止其执行成功，也删除付款业务。

(2)在所述数据处理系统中，没有与第一业务相同或互斥的第二业务执行成功。也就是所述数据表中没有与第一业务相同或互斥的第二业务对应的执行成功的标识信息。在没有与第一业务相同或互斥的第二业务执行成功时，也会有两种情况：(a)不存在与第一业务相同或互斥的第二业务正在执行。(b)存在与第一业务相同或互斥的第二业务正在执行。

下面，基于步骤S102、S103、S104、S105来详细介绍，如何区分上述(a)、(b)两种情况，以及在这两种情况下，对第一业务作如何处理。

S102：执行为所述第一业务设置对应的第一标识信息的操作。

在具体实施过程中，服务器将第一业务对应的第一标识信息插入一公共信息表中，该公共信息表位于一数据库中，所述公共信息表为一临时表，也就是该公共信息表中的数据可以更改和删除，与前面所述的存储执行成功标识信息的数据表为不同类型的表。数据库的事务特性中包括分离性，所谓分离性指的是并发的事务是相互隔离的，即一个事务的内部操作以及正在操作的数据必须封锁起来，不被其他企图进行修改的事务看到。故而，如果第一业务，比如付款业务正在执行，那么服务器在公共信息表中是查找不到第一业务对应的第一标识信息的。因此，不能基于所述第一标识信息直接判断在所述数据处理系统中是否存在第二业务正在执行。但是数据库还有一特性，就是如果该数据库中已经存在某一数据，那么没法再于所述数据库中插入相同的数据。而在本申请中，与第一业务相同或互斥的业务的第一标识信息是相同的。故而，如果在获得第一业务时，于所述公共信息表中插入了所述第一标识信息，则表示之后的第二业务无法将其标识信息插入所述公共信息表中，而如果所述公共信息表中在第一业务插入所述第一标志信息之前，已经有插入第二业务对应的第一标识信息的话，则无法将第一业务对应的第一标识信息插入所述公共信息表。

S103：判断是否成功设置了所述第一标识信息；如果判断结果为是，转向S104；如果判断结果为否，转向S105。

S104：在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述数据处理系统中没有与所述第一业务关系为相同或互斥的第二业务正在被执行。

在能够成功设置所述第一标识信息时，表明在所述数据表中不存在所述第一标识信息，也就是在所述数据处理系统中没有第二业务正在执行，那么所述服务器直接执行第一业务。

S105:在不能成功设置所述第一标识信息时，暂停所述第一业务。

由于在不能成功设置所述第一标识信息时，表明所述数据处理系统中已经存在第二业务正在执行，如果这时候继续执行第一业务，必然导致相同或是互斥的业务执行两次，这将会导致严重的BUG，故而所述服务器要暂停执行第一业务，以等待第二业务执行的结果。

第二业务如果执行成功，会于数据库中写入一执行成功的标识，第一业务看到这个标识，就会删除第一业务。

第二业务如果执行失败，也会及时将执行失败的消息通知所述第一业务，第一业务将会按照第二业务执行的步骤继续执行。

另外，不管是第一业务还是第二业务在执行成功后，为避免冗余数据，所述服务器都会从公共信息表中删除对应的第一标识信息。

上述技术方案，由于先执行为所述第一业务设置对应的第一标识信息的操作；然后判断是否成功设置了所述第一标识信息；在成功设置了所述第一标识信息时，才执行所述第一业务；所以，保证在系统中已经存在与所述第一业务关系为相同或互斥的第二业务时，第一业务不会被执行，进而有效的达到了采用较为简便的方式即可实现关系为相同或互斥的业务幂等性的技术效果。

下面再通过两个具体的例子，对本申请实施例一中涉及的服务器对客户端发送至网络购物平台的业务进行处理的技术方案进行详细说明。

实施例二

为了使本领域技术人员更加详尽了解本申请的技术方案，本申请实施例二以第一业务为付款业务、第二业务为与第一业务相同的付款业务为例，来介绍在并发环境下对于同一商品多次付款业务同时执行时，所述服务器作如何处理。本申请实施例二中的方法所运行的系统和本申请实施例一中的方法所运用的系统相同。

其中，付款业务B为对商品A的付款业务，付款业务B包括三次相同的付款业务，分别为付款业务B1、付款业务B2以及付款业务B3。并且付款业务B1、B2、B3的标识信息相同，皆为第一标识信息。如图2所示，为本申请实施例二中同一商品的多次付款业务并发执行的处理步骤示意图。

S201：启动本地事务，也就是获得当前付款业务，这里选取付款业务B1为当前付款业务，而付款业务B2、付款业务B3可能执行时间位于付款业务B1前，也可能于付款业务B1后，但是，在付款业务B1执行时，并不知道付款业务B2、B3的执行情况。

S202：判断能否于公共信息表中插入第一标识信息，这里的第一标识信息指的是付款业务B对应的标识信息；如果判断结果为否，转向S203；如果判断结果为是，转向S204。

S203：由于判断结果为否，由实施例一可知，如果不能于公共信息表中插入付款业务B1对应的第一标识信息，则表示公共信息表中存在第一标识信息，也就是存在付款业务B正在执行，这里的第一标识信息可能是由付款业务B2插入的，也可能是由付款业务B3插入的，故而所述服务器暂停执行付款业务B1，以等待与付款业务B1相同的付款业务执行的结果。

S204：由于判断结果为是，故而表明所述数据处理系统中并不存在与付款业务B1对应的付款业务业务正在执行。但是，也有可能在所述数据处理系统中已经存在付款业务B执行成功的记录。为了防止重复操作，故而要于存储执行成功的标识信息的数据表中查找是否存在该付款业务对应的执行成功的标识信息。如果不存在执行成功的标致信息，转向S206；如果存在执行成功的标识信息，转向S205。

S205：因为存在执行成功的标识信息，表明该付款业务B已经执行成功，故而为了防止重复执行成功，删除付款业务B1。

S206：因为不存在执行成功的标识信息，表明该付款业务B并未执行成功，故而可以执行付款业务B1对应的业务。

S207：在付款业务B1执行成功后，为了防止冗余数据，故而所述服务器要删除付款业务B1对应的第一标识信息。

S208：在删除第一标识信息后，所述服务器提交本地事务，也就是提交付款业务对应的执行日志以及执行成功的标识信息。

在具体实施过程中，步骤S204中，所述服务器于存储成功的标识信息的数据表中查找是否存在该付款业务对应的执行成功的标识信息的步骤也可以和步骤S202判断能否于公共信息表中插入第一标识信息的步骤互换，也就是先判断是否在数据表中是否存在执行成功的标识信息，如果存在所述执行成功的标识信息的话，直接不插入第一标识信息，只有在不包含执行成功的标识信息时，才需要判断能否将第一标识信息插入公共信息表。在本申请中，对于这两个步骤的先后顺序不作限制。

上述技术方案，由于采用了在执行付款业务时，先判断能否于公共信息表中设置付款业务对应的第一标识信息，当成功设置第一标识信息时，才执行退款业务的技术方案，所以，保证了在同一商品的付款业务多次启动时，只有一次付款业务能够执行成功的技术效果。

实施例三

在本申请实施例二，以第一业务和第二业务为相同业务时，服务器的处理情况，在本申请实施例三将基于第一业务和第二业务为互斥业务时，介绍服务器的处理情况。其中，以产品B的付款业务为第一业务，产品B的付款失败资金退回业务作为第二业务。

如图3所示，为本申请实施例三中服务器对于同一产品的付款业务和付款失败资金退回业务并发执行时的处理流程图。

其中,后缀名为A的表示产品B的付款业务的流程，后缀名为B的表示产品B的退款业务的流程。

比如，如果付款业务执行成功，服务器将从网银或者支付宝转账到卖家账户，而如果付款业务执行失败，服务器将钱原路返回卖家银行卡或支付宝，在同一时刻，这两项业务必然只有一项成功，故而，在确定付款业务成功时，服务器要确认钱是否已经退回银行卡；而在确定付款失败资金退回业务成功时，服务器也要确认是否已经付款成功。

假设，付款业务于T1时刻进行，退款业务于T2时刻进行，T1时刻早于T2时刻。下面基于各个步骤来详细介绍，在同一时间，既存在对商品B的付款业务，又存在对商品B的付款失败资金退回业务时，服务器对商品B的付款业务和退款业务的处理流程。如图3所示，包括如下步骤：

S301A：在T1时刻，启动付款业务；

S301B:在T2时刻，启动退款业务；

S302A:向公共信息表中，插入付款业务对应的第一标识信息，由于T1时刻早于T2时刻，故而，此时公共信息表中不包含退款业务对应的第一标识信息，也就是退款业务尚未处理，故而能成功于公共信息表中插入第一业务对应的第一标识信息；

S303A：在成功向公共信息表中写入付款业务对应的第一标识信息后，即可处理付款业务；

S304A:提交付款业务。在付款业务处理成功后，于一存储设备中，写入该付款业务对应的永久信息以及删除第一标识信息。该付款业务对应的永久信息包括：该业务的业务号，业务执行状态以及其他一些信息。比如，如果是对商品B的付款业务，那么就包括这些信息：交易号(也就是对商品B购物过程中的唯一标识信息)；付款渠道，比如是通过网银付款、红包付款、积分付款或者支付宝余额付款等等；操作类型，比如付款业务、收费业务、退款业务等；付款结果；付款金额；付款时间等等。由于在提交付款业务后，会删除对应的第一标识信息，那么与该付款业务相同或者互斥的业务，比如商品B的退款业务，就可以将第一标识信息插入公共信息表，但是由于付款业务已经执行成功，也就是已经确认用户对商品B进行了付款，如果再执行退款业务，那么，付出去的钱又退还给了用户，也就是用户在没有付款的情况下，获得了商品。故而，为了防止在付款业务执行成功后，再执行退款业务，将于一数据表中写入一执行成功的标识信息。

S302B：由于在公共信息表中，已经存在第一标识信息，故而在处理退款时，是不能插入退款业务对应的第一标识信息的；

S303B:由于不能在公共信息表中插入退款业务对应的第一标识信息，故而说明，有与退款业务对应的互斥业务，比如付款业务正在进行，故而退款业务要等待付款业务执行的结果，执行结果包括如下两种情况：

(1)付款业务执行成功，基于步骤S304A可知，如果付款业务执行成功，将会于数据表中写入执行成功的标识信息，那么基于该执行成功的标识信息，即可获得付款业务成功的信息，在这种情况下，删除退款业务。

(2)付款业务执行失败，那么服务器按照执行付款业务的流程执行所述退款业务。

自然，在具体实施过程中，也可以在执行于公共信息表中插入第一标识信息之前或者在插入第一标识信息之后，判断存放执行成功的标识信息的数据表中，是否存在商品B付款业务或者其逆向业务(也就是付款失败资金退回)的执行成功的标识信息，在不存在所述执行成功的标识信息时，才继续处理付款业务或付款失败资金退回业务。由于在本申请实施例一和实施例二中，已经介绍，在此不再赘述。

上述技术方案，由于采用了在执行付款业务时，先判断能否于公共信息表中设置付款业务对应的第一标识信息，当成功设置第一标识信息时，才执行退款业务的技术方案，所以，保证了在同一商品的付款业务和付款失败资金回退业务并发进行时，付款业务和付款失败资金回退业务只有一个能执行成功的技术效果。

实施例四

请参考图4，本申请实施例四提供一种业务处理的装置，应用在用于对数据进行处理的系统中，所述装置包括：

获得单元401：用于获得第一业务；

设置单元402：用于执行为所述第一业务设置对应的第一标识信息的操作；

判断单元403：用于判断是否成功设置了所述第一标识信息；

执行单元404：用于在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行。

由于本申请实施例四中的装置为与实施本申请实施例一、二、三中的方法所对应的装置，所以基于本申请实施例一、二、三中的方法，本领域所属技术人员能够了解本申请实施例四中的装置的具体结构以及本申请实施例四的装置的各种变化形式。所以在此对于该装置不再详细介绍。只要本领域所属技术人员实施本申请实施例一、二、三中的方法所采用的装置，都属于本申请所欲保护的范围。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (4)

1.一种业务处理的方法，应用在用于对数据进行处理的系统中，其特征在于，所述方法包括：

服务器获得第一业务；所述第一业务为客户端发送至网络购物平台的业务；

判断数据表中是否包含所述第一业务对应的执行成功的标识，如果所述数据表不存在所述执行成功的标识，执行为所述第一业务设置对应的第一标识信息的操作，具体为：将所述第一标识信息插入一公共信息表；

判断是否成功设置了所述第一标识信息；

在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行；

获得第一执行结果，所述第一执行结果用来表明执行所述第一业务是否成功；

在所述第一执行结果表明执行所述第一业务成功时，于所述数据表中，为所述第一业务设置所述执行成功的标识；

在所述第一业务执行成功后，从公共信息表中删除对应的第一标识信息；

在没有成功设置所述第一标识信息时，获得一第二执行结果，其中，所述第二执行结果用来表明执行与所述第一业务关系为相同或互斥的第二业务是否成功；

在所述第二执行结果表明执行所述第二业务没有成功时，执行所述第一业务；

在所述第二执行结果表明执行所述第二业务成功时，删除所述第一业务。

2.如权利要求1所述的方法，其特征在于，在判断所述数据表中是否包含所述执行成功的标识之后，所述方法还包括：

如果所述数据表中存在所述执行成功的标识，删除所述第一业务。

3.如权利要求1所述的方法，其特征在于，在为所述第一业务设置一执行成功的标识之后，所述方法还包括：

删除所述第一标识信息。

4.一种业务处理的装置，应用在用于对数据进行处理的系统中，其特征在于，所述装置包括：

获得单元：用于获得第一业务；所述第一业务为客户端发送至网络购物平台的业务；

设置单元：用于判断数据表中是否包含所述第一业务对应的执行成功的标识，如果所述数据表不存在所述执行成功的标识，执行为所述第一业务设置对应的第一标识信息的操作，具体为：将所述第一标识信息插入一公共信息表；

判断单元：用于判断是否成功设置了所述第一标识信息；

执行单元：用于在成功设置了所述第一标识信息时，执行所述第一业务，其中，在成功设置了所述第一标识信息时，表明所述系统没有与所述第一业务关系为相同或互斥的第二业务正在被执行；获得第一执行结果，所述第一执行结果用来表明执行所述第一业务是否成功；在所述第一执行结果表明执行所述第一业务成功时，于所述数据表中，为所述第一业务设置所述执行成功的标识；在所述第一业务执行成功后，从公共信息表中删除对应的第一标识信息；在没有成功设置所述第一标识信息时，获得一第二执行结果，其中，所述第二执行结果用来表明执行与所述第一业务关系为相同或互斥的第二业务是否成功；在所述第二执行结果表明执行所述第二业务没有成功时，执行所述第一业务；在所述第二执行结果表明执行所述第二业务成功时，删除所述第一业务。