CN112766956A - 基于分布式订单系统的订单支付控重方法及装置 - Google Patents

Abstract

本发明可用于金融领域或其他领域，本发明提供了一种基于分布式订单系统的订单支付控重方法及装置，基于分布式订单系统的订单支付控重方法包括：响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；判断用户支付是否成功；若是，判断用户的支付行为是否唯一；若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。本发明通过数据库乐观锁实现在分布式场景下订单控重，通过订单集群一次带条件的状态更新实现订单不重复支付。在不引入分布式锁的情况下，降低系统部署复杂度，减少下节点间服务交互，降低了开发复杂度，提高系统处理效率。

Description

基于分布式订单系统的订单支付控重方法及装置

技术领域

本发明属于大数据技术领域，具体涉及一种基于分布式订单系统的订单支付控重方法及装置。

背景技术

随着移动支付的广泛普及，特别是在零售支付场景中，因为交易量大，交易处理时效要求较高，支付系统一般会采用分布式技术来实现。具体地：根据微服务的架构，订单支付系统中一般分为商户订单集群，商户所属集群、付款方订单集群和个人账户集群等多个独立集群，其中商户订单集群负责商户方的订单生命周期管理，付款方订单集群负责付款方订单管理，为了支持收单商户和付款用户归属不同机构，两个订单系统分属不同集群，商户所属集群和个人账户集群分别负责商户和用户的资金收付。完成一笔订单的支付，需在两个订单系统下单，然后扣减个人用户的账户资金，增加商户账号资金。因交易过程中涉及多个集群，交易流程较长，系统在提高处理效率同时需控制交易重复发起，并保证交易一致性。

这里以付款方账户和收单机构不是同一家机构情况下用户主扫商户收款码为例，用户使用支付工具主动扫商户动态收款码。付款方所在系统收到用户发起的支付请求后先查询收款动态码的信息，包括收款方账户信息、机构信息以及订单信息等，获取这些信息后在付款方所在系统下单并提示用户输入金额，如果金额超过免密支付限额，则还需输入支付密码，然后扣减用户资金，并通知收款方机构入账。在这个过程中，对于同一笔订单需要满足以下控制机制。

1、一笔订单有且仅有一次成功支付，假设有人重复扫码，或多人扫相同订单收款码只能有一个人支付成功。

2、用户在支付失败的情况下，可以重新发起支付。

对于上述要求，系统处理流程如下，

1、个人账户集群查询商户订单信息后首先在付款方订单集群登记一笔付款订单，订单状态待支付。

2、用户输入金额后，系统在个人账户集群登记一笔付款指令，状态为支付中

3、个人账户集群调用付款方订单集群服务更新订单状态为支付中。

4、系统判断是否需要用户输支付密码，如果需要则提示用户输入，否则继续。

5、个人账户集群匹配支付密码成功并扣减用户资金，更新支付指令状态已扣账。

6、个人账户集群调用付款方订单集群服务更新订单状态为支付成功。

7、个人账户集群更新支付指令状态为支付成功，并通知商户入账。

以上流程涉及到付款方集群和收单集群3次远程调用，如果要控重需要引入分布式锁，比如redis或zookeeper，但这种情况会大大增加系统的复杂度。

发明内容

需要说明的是，本公开基于分布式订单系统的订单支付控重方法及装置可用于金融领域，也可用于除金融领域之外的任意领域，本发明对此不做限定

针对现有技术中的问题，本发明通过数据库乐观锁实现在分布式场景下订单控重，通过订单集群一次带条件的状态更新实现订单不重复支付。在不引入分布式锁的情况下，降低系统部署复杂度，减少下节点间服务交互，降低了开发复杂度，提高系统处理效率。

为解决上述技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种基于分布式订单系统的订单支付控重方法，包括：

响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

判断用户支付是否成功；

若是，判断用户的支付行为是否唯一；

若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

一实施例中，在所述判断用户支付是否成功之前，还包括：

根据所述订单支付请求在所述用户订单集群中登记。

一实施例中，所述根据所述订单支付请求在所述用户订单集群中登记包括：

根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

在所述账号中登记待支付状态。

一实施例中，基于分布式订单系统的订单支付控重方法还包括：

当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户。

一实施例中，在所述订单集群中更新所述订单支付状态为已支付包括：

利用乐观锁方法，更新所述订单支付状态为已支付。

第二方面，本发明提供一种基于分布式订单系统的订单支付控重装置，包括：

状态标记第一模块，用于响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

第一判断模块，用于判断用户支付是否成功；

第二判断模块，用于若是，判断用户的支付行为是否唯一；

状态标记第二模块，用于若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

一实施例中，登记模块，用于根据所述订单支付请求在所述用户订单集群中登记；

支付消息发送模块，用于当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户；

过期消息发送模块，用于当用户支付超过预设时间时，发送订单过期消息至用户；

所述登记模块包括：

账号路由单元，用于根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

状态登记单元，用于在所述账号中登记待支付状态；

状态标记第二模块具体用于利用乐观锁方法，更新所述订单支付状态为已支付。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现基于分布式订单系统的订单支付控重方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现基于分布式订单系统的订单支付控重方法的步骤。

从上述描述可知，本发明实施例提供的基于分布式订单系统的订单支付控重方法及装置，首先响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；接着，判断用户支付是否成功；若是，判断用户的支付行为是否唯一；若是，最后在订单集群中更新订单支付状态为第二状态，以完成订单支付。本发明通过利用订单并发支付特点，通过数据库乐观锁，来简化订单处理流程，减少交易过程中跨集群交互次数，提高了系统处理处理效率，在大并发场景下，可以在控重和处理效率上获取较好的平衡。

附图说明

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

图1为本发明的实施例中基于分布式订单系统的订单支付控重方法流程示意图一；

图2为本发明的实施例中基于分布式订单系统的订单支付控重方法流程示意图二；

图3为本发明的实施例中步骤500的流程示意图；

图4为本发明的实施例中基于分布式订单系统的订单支付控重方法流程示意图三；

图5为本发明的实施例中步骤400的流程示意图；

图6为本发明的实施例中基于分布式订单系统的订单支付控重方法流程示意图四；

图7为本发明的具体应用实例中基于分布式订单系统的订单支付控重方法的流程示意图；

图8为本发明的具体应用实例中分布式订单支付控重装置的连接示意图；

图9为本发明的具体应用实例中基于分布式订单系统的订单支付控重装置结构框图一；

图10为本发明的具体应用实例中基于分布式订单系统的订单支付控重装置结构框图二；

图11为本发明的实施例中登记模块50的结构框图；

图12为本发明的实施例中的电子设备的结构示意图。

具体实施方式

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本发明的实施例提供一种基于分布式订单系统的订单支付控重方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付。

这里以一移动支付场景来解释步骤100，用户通过移动设备扫描商户的收款码，响应于该二维码，在订单集群中标记该笔订单的支付状态为待支付。

步骤200：判断用户支付是否成功。

步骤300：若是，判断用户的支付行为是否唯一；

在步骤200以及步骤300中，首先判断是否收到该用户的付款，如果是，则进一步判断该订单的支付款(支付行为)是否唯一(需要说明的是，该订单必须唯一)，如果该订单的支付行为唯一，即用户只付过一次款，则进行步骤400.

步骤400：若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

可以理解的是，在分布式支付系统中，一般分为商户订单集群，商户所属集群、付款方订单集群和用户账户集群等多个独立集群，商户订单集群负责商户方的订单生命周期管理，付款方订单集群负责付款方订单管理，为了支持收单商户和付款用户归属不同机构，两个订单系统分属不同集群，商户所属集群和用户账户集群分别负责商户和用户的资金收付。在步骤400中，如果步骤300的判断结果为用户只进行过一次支付行为时，则在订单集群中将订单支付状态更新为支付成功(第二状态)。

从上述描述可知，本发明实施例提供的基于分布式订单系统的订单支付控重方法，首先响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；接着，判断用户支付是否成功；若是，判断用户的支付行为是否唯一；若是，最后在订单集群中更新订单支付状态为第二状态，以完成订单支付。本发明所提供的方法可使支付系统在不引入分布式事务和分布式锁，不降低系统并发度的情况下，防止订单重复支付。

一实施例中，参见图2，基于分布式订单系统的订单支付控重方法在步骤200之前还包括：

步骤500：根据所述订单支付请求在所述用户订单集群中登记。

可以理解的是，通过将订单支付请求在用户订单集群中进行登记，以实时标记该订单的状态，一可以防止用户的重复支付，另一方面，也可以避免现有技术中将该订单进行锁定，而给系统造成过大负担的问题。

一实施例中，参见图3，步骤500进一步包括：

步骤501：根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

需要说明的是，步骤501中的路由(routing)是指分组从源到目的地时，决定端到端路径的网络范围的进程。具体地，路由是指从一个接口上收到数据包，根据数据包的目的地址进行定向并转发到另一个接口的过程。路由通常与桥接来对比，主要区别在于桥接发生在OSI参考模型的第二层(数据链路层)，而路由发生在第三层(网络层)。这一区别使二者在传递信息的过程中使用不同的信息，从而以不同的方式来完成其任务。

步骤502：在所述账号中登记待支付状态。

在步骤501以及步骤502中，首先根据订单支付请求在用户订单集群中匹配到该用户的账号，并在该账号中标定该订单为待支付状态。

一实施例中，参见图4，基于分布式订单系统的订单支付控重方法还包括：

步骤600：当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户。

可以理解的是，从开始没有将该笔订单进行锁定，从而有必要在判断用户是否进行重复支付，如果发现用户尝试多次支付(即针对同一订单发送多次支付请求)，则告知用户已经支付，请勿重复支付。

一实施例中，参见图5，步骤400包括：

步骤401：利用乐观锁方法，更新所述订单支付状态为已支付。

可以理解的是，当程序中可能出现并发的情况时，就需要保证在并发情况下数据的准确性，以此确保当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的。这种手段就叫做并发控制。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。没有做好并发控制，就可能导致脏读、幻读和不可重复读等问题。

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。乐观锁适用于读操作多的场景，这样可以提高程序的吞吐量。

乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言，也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。乐观锁的实现方式如下：

CAS实现：Java中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种CAS实现方式。

版本号控制：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数。当数据被修改时，version值会+1。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值与当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

需要说明的是，乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

一实施例中，参见图6，基于分布式订单系统的订单支付控重方法还包括：

步骤700：当用户支付超过预设时间时，发送订单过期消息至用户。

为进一步地说明本方案，本发明还提供基于分布式订单系统的订单支付控重方法的具体应用实例，具体包括如下内容，参见图7。

在分布式订单系统中，客户扫码支付场景下，首先根据订单号在订单集群中登记一笔订单，状态为待支付并在5分钟后过期，该笔订单必须唯一，如果纪录重复则判断订单状态是否支付成功，若是，则返回订单已支付；否则判断订单是否过期，如果是则返回订单过期，否则继续后续处理；其次在个人账户集群扣减客户账户，成功后，更新订单状态；在订单集群使用乐观锁更新订单状态为支付成功，即带更新条件为订单状态为待支付；如果更新失败，则表明订单已支付，通知个人账户集群冲正；如果更新成功，则通知商户入账，具体地：

步骤S101，用户扫描商户收款动态二维码；

步骤S102，订单集群登记付款订单信息状态待支付。

系统根据收款码信息查询商户所在机构，获取到订单信息后，根据订单号路由到付款方订单集群登记一笔订单，状态为待支付；

步骤S103，用户录入支付金额，发起支付。

系统展示订单，并提示用户输入金额，发起支付；

步骤S104，个人账户集群完成用户扣款。

系统在个人账户集群登记支付指令，并完成扣款处理；

步骤S105，付款方订单集群将订单状态从待支付改成已支付。

如果更新成功则进行步骤S106。

步骤S106，更新支付指令支付成功。

个人账户集群更新支付指令为支付成功。

步骤S107，通知商户入账。

个人账户集群通知商户入账。如果更新失败，则进行步骤S108.

步骤S108，个人账户集群冲账。

个人账户集群进行冲账，更新支付指令状态为已冲账。

步骤S109，将付款方订单状态通知商户。

个人账户集群通知商户付款方订单支付结果。

如图8是本发明的一种分布式订单支付控重装置的连接示意图，该系统包括：客户交易终端100、个人付款集群200、付款方订单集群300、商户订单集群400和商户所在集群500；个人付款集群200、付款方订单集群300、商户订单集群400和商户所在集群500可以通过内部网相连接；或者个人付款集群200、付款方订单集群300和商户订单集群400、商户所在集群500分属不同机构，通过互联网相连。

从上述描述可知，本发明具体应用实例所提供一种基于分布式订单系统的订单支付控重方法，首先响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；接着，判断用户支付是否成功；若是，判断用户的支付行为是否唯一；若是，最后在订单集群中更新订单支付状态为第二状态，以完成订单支付。本发明的有益效果在于，通过使用本发明订单支付控重的方法，一方面，简化处理流程，没有引入分布式锁，没有给系统增加复杂度，另一方面，引入订单失效时间和乐观锁机制，通过更新订单状态时带上前序状态来控制重复支付，简单高效，没有大事务，处理效率高，不仅如此，乐观锁机制简单，没有引入额外的跨集群处理，开发工作量较低。

基于同一发明构思，本申请实施例还提供了一种基于分布式订单系统的订单支付控重装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于基于分布式订单系统的订单支付控重装置解决问题的原理与基于分布式订单系统的订单支付控重方法相似，因此基于分布式订单系统的订单支付控重装置的实施可以参见基于分布式订单系统的订单支付控重方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现基于分布式订单系统的订单支付控重方法的基于分布式订单系统的订单支付控重装置的具体实施方式，参见图9，基于分布式订单系统的订单支付控重装置具体包括如下内容：

状态标记第一模块10，用于响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

第一判断模块20，用于判断用户支付是否成功；

第二判断模块30，用于若是，判断用户的支付行为是否唯一；

状态标记第二模块40，用于若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

一实施例中，参见图10，基于分布式订单系统的订单支付控重装置还包括：

登记模块50，用于根据所述订单支付请求在所述用户订单集群中登记；

支付消息发送模块60，用于当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户；

过期消息发送模块70，用于当用户支付超过预设时间时，发送订单过期消息至用户；

一实施例中，参见图11，所述登记模块50包括：

账号路由单元501，用于根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

状态登记单元502，用于在所述账号中登记待支付状态；

状态标记第二模块40具体用于利用乐观锁方法，更新所述订单支付状态为已支付。

从上述描述可知，本发明具体应用实例所提供一种基于分布式订单系统的订单支付控重装置，首先响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；接着，判断用户支付是否成功；若是，判断用户的支付行为是否唯一；若是，最后在订单集群中更新订单支付状态为第二状态，以完成订单支付。本发明的有益效果在于，通过使用本发明订单支付控重的方法，一方面，简化处理流程，没有引入分布式锁，没有给系统增加复杂度，另一方面，引入订单失效时间和乐观锁机制，通过更新订单状态时带上前序状态来控制重复支付，简单高效，没有大事务，处理效率高，不仅如此，乐观锁机制简单，没有引入额外的跨集群处理，开发工作量较低。

本申请的实施例还提供能够实现上述实施例中的基于分布式订单系统的订单支付控重方法中全部步骤的一种电子设备的具体实施方式，参见图12，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(CommunicationsInterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备以及客户端设备等相关设备之间的信息传输；

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的基于分布式订单系统的订单支付控重方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

步骤200：判断用户支付是否成功；

步骤300：若是，判断用户的支付行为是否唯一；

步骤400：若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

本申请的实施例还提供能够实现上述实施例中的基于分布式订单系统的订单支付控重方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于分布式订单系统的订单支付控重方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

步骤200：判断用户支付是否成功；

步骤300：若是，判断用户的支付行为是否唯一；

步骤400：若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (10)

1.一种基于分布式订单系统的订单支付控重方法，其特征在于，包括：

响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

判断用户支付是否成功；

若是，判断用户的支付行为是否唯一；

若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

2.根据权利要求1所述的订单支付控重方法，其特征在于，在所述判断用户支付是否成功之前，还包括：

根据所述订单支付请求在所述用户订单集群中登记。

3.根据权利要求2所述的订单支付控重方法，其特征在于，所述根据所述订单支付请求在所述用户订单集群中登记包括：

根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

在所述账号中登记待支付状态。

4.根据权利要求1所述的订单支付控重方法，其特征在于，还包括：

当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户。

5.根据权利要求1所述的订单支付控重方法，其特征在于，包括：在所述订单集群中更新所述订单支付状态为已支付包括：

利用乐观锁方法，更新所述订单支付状态为已支付。

6.根据权利要求1所述的订单支付控重方法，其特征在于，还包括：

当用户支付超过预设时间时，发送订单过期消息至用户。

7.一种基于分布式订单系统的订单支付控重装置，其特征在于，包括：

状态标记第一模块，用于响应于与用户的订单支付请求，在订单集群中标记订单支付状态为待支付；

第一判断模块，用于判断用户支付是否成功；

第二判断模块，用于若是，判断用户的支付行为是否唯一；

状态标记第二模块，用于若是，在所述订单集群中更新所述订单支付状态为已支付，以完成订单支付。

8.根据权利要求7所述的订单支付控重装置，其特征在于，还包括：

登记模块，用于根据所述订单支付请求在所述用户订单集群中登记；

支付消息发送模块，用于当用户的支付行为是否唯一的判断结果为不唯一时，发送已经支付消息至用户；

过期消息发送模块，用于当用户支付超过预设时间时，发送订单过期消息至用户；

所述登记模块包括：

账号路由单元，用于根据所述订单支付请求路由至所述用户订单集群中用户对应的账号；

状态登记单元，用于在所述账号中登记待支付状态；

状态标记第二模块具体用于利用乐观锁方法，更新所述订单支付状态为已支付。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至6任一项所述基于分布式订单系统的订单支付控重方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6任一项所述基于分布式订单系统的订单支付控重方法的步骤。

Images