CN110297716B - 一种网络交易方法及装置 - Google Patents

Abstract

本发明公开了一种网络交易方法及装置，该网络交易方法包括：第一应用依次向第二应用发送交易请求报文和查询请求报文；当交易请求报文和查询请求报文到达第二应用时都分别进行抢锁操作，其中，交易请求报文和查询请求报文之中后到达第二应用的一者抢锁失败；其中，在交易请求报文抢锁成功的情况下，第二应用受理第一应用的交易请求；在交易请求报文抢锁失败的情况下，第二应用向第一应用返回交易失败。通过本发明的上述技术方案，能够实现同一笔交易流水在网络延迟或系统应用故障场景下保证交易状态一致性。

Description

一种网络交易方法及装置

技术领域

本发明涉及互联网技术领域，具体来说，涉及一种网络交易方法及装置，更具体地，涉及一种实现同一笔交易流水在网络延迟或系统应用故障场景下保证交易状态一致性的方法。

背景技术

通常，在交易系统中，交易发起方发起一笔交易，如果交易返回受理中、未明或超时，交易发起方会发起一笔对该笔交易的查询操作。而每笔交易会经过多个应用，在此以A应用、B应用来代替应用；每笔交易请求报文顺序是由A应用到B应用。在分布式集群环境中，由于网络延迟或某个应用出现故障的场景下，可能会导致查询请求报文先于交易请求报文到达B应用，此时在B应用的查询流程中因为无原交易信息，查询结果为交易不存在。

如果在B应用的查询流程中交易不存在，以失败状态返给A应用，明确告诉A应用此笔交易为失败。但当交易请求报文随后到达B应用时，又会按交易正常逻辑处理，导致这笔交易重新受理，其实查询请求报文已经告知A应用该笔交易失败，最终造成了交易状态错误。如果在付款场景下最终会造成资金损失，在收款场景下则会多扣一笔钱。

如果在B应用的查询流程中交易不存在，以未明状态返给A应用，A应用会不断的发起查询，直到查回最终的交易状态。如果是因为集群环境中的某一个B应用故障导致的交易请求报文根本没有接收到或发送出去，而在B应用或系统内部消耗掉了，则这笔交易状态一直都查询不回来，有可能需要等到对账后才知道最终状态，延长了交易处理时间，超出用户可预期的范围或导致更差的用户体验。

现有的一种行业通用做法如下：

如图1所示，正常情况下，A应用发出的交易请求报文优先到达B应用，B应用正常受理，直接初始交易入库执行正常流程，在B应用交易流程中如果交易存在则返回重复交易，直接结束流程。B应用交易流程处理后，当A应用发出的查询请求报文到达B应用时，在查询流程中判断交易存在，执行正常流程，返回交易结果。

如图2所示，在网络延迟的场景下，查询请求先于交易请求到达B应用，查询过程中交易不存在，以失败状态返回给A应用，A应用更新交易状态为失败。当延迟的交易请求报文后到达B应用时，如图2中的步骤10、步骤11、步骤12，B应用会正常受理，B应用更新交易为成功，交易请求报文以成功响应给A应用时，由于A应用中交易已经为失败终态，不会再更新交易为成功，这就导致了A应用与B应用的交易状态不一致。

如图3所示，在集群环境某个节点出故障的场景下，当A应用发出的请求到达集群里的B1应用时，由于B1应用故障导致交易阻塞在系统层面，交易长时间不会受理。A应用读超时链路关闭。后续查询请求到达时，分发到集群的B2应用上，查询流程中交易不存在，以失败状态返回给A应用，A应用更新交易状态未失败。但是僵死的B1应用经过人工处理或者某种场景例如kill-3后自动恢复，接收到了步骤1发送的交易请求报文，B1应用正常受理，更新交易为成功，由于原交易链路已经关闭，导致无法响应给A应用。最终导致了A应用与B应用的交易状态不一致。

如图4所示，在集群环境某个节点出故障且查询交易不存在以未明状态返回的场景下，当B1应用挂掉恢复不了，交易请求未到达B1应用，查询请求如果查到交易不存在，以未明的状态返回给A应用。由于A应用得到的是未明状态，A应用会进行很多次或在事先定义好的策略下进行查询，由于交易请求报文丢失或B1应用恢复不了，交易会一直不存在，查询一直查不回来交易最终状态，必须等到对账才能确定最终的交易状态，延长了交易处理时间。

但是，上述现有的行业技术方案具有以下缺点：

无法保证交易状态一致性：B应用在查询直接返回失败，可能造成A应用与B状态不一致。由于网络或系统应用等故障原因，在查询请求报文先与交易请求报文到达场景下，查询流程中查询到交易不存在，以失败状态返回，当交易请求报文后到达时，会造成应用之间交易状态不一致。如果在付款场景下会给公司造成资金损失，在收款场景下都扣一笔钱。

时效性差：通过查询返回未明、通过对账保证一致性，但是会增加状态一致性的时间。查询请求报文先与交易请求报文到达时，查询到交易不存在，如果以未明状态返回，则会不断的发起查询，直到查询到交易最终状态。在集群中某节点系统僵死交易请求报文丢失的情况下，必须等对完账才能确定最终状态，大大延长了交易处理时间。

发明内容

针对相关技术中上述的问题，本发明提出一种网络交易方法及装置，能够实现同一笔交易流水在网络延迟或系统应用故障场景下保证交易状态一致性。

本发明的技术方案是这样实现的：

根据本发明的一个方面，提供了一种网络交易方法，包括：

第一应用依次向第二应用发送交易请求报文和查询请求报文；

当交易请求报文和查询请求报文到达第二应用时都分别进行抢锁操作，其中，交易请求报文和查询请求报文之中后到达第二应用的一者抢锁失败；

其中，在交易请求报文抢锁成功的情况下，第二应用受理第一应用的交易请求；在交易请求报文抢锁失败的情况下，第二应用向第一应用返回交易失败。

根据本发明的实施例，在进行抢锁操作之前还包括：生成锁的锁值，其中，锁值是通过哈希算法对交易请求报文和查询请求报文的共有字段进行计算得到的。

根据本发明的实施例，生成锁的锁值包括：为锁设置有效期；其中，在有效期内，拦截到达第二应用的交易请求；在锁失效后，受理到达第二应用的交易请求。

根据本发明的实施例，当交易请求报文和查询请求报文到达第二应用时都分别进行抢锁操作包括：交易请求报文受到延迟使得查询请求报文比交易请求报文先到达第二应用；查询请求报文抢锁成功，向第一应用返回交易失败；在查询请求报文抢锁成功之后，交易请求报文到达第二应用；交易请求报文抢锁失败，再次向第一应用返回交易失败。

根据本发明的另一方面，提供了一种网络交易装置，包括第一应用端和第二应用端；第一应用端包括请求发送模块，用于依次向第二应用端发送交易请求报文和查询请求报文，其中，交易请求报文和查询请求报文到达第二应用端时都分别进行抢锁操作，交易请求报文和查询请求报文之中后到达第二应用端的一者抢锁失败；

第二应用端包括请求响应模块，用于在交易请求报文抢锁成功的情况下，受理第一应用端的交易请求，还用于在交易请求报文抢锁失败的情况下，向第一应用端返回交易失败。

根据本发明的实施例，第二应用端还包括：锁生成模块，用于生成锁的锁值；其中，锁值是通过哈希算法对交易请求报文和查询请求报文的共有字段进行计算得到的。

根据本发明的实施例，锁生成模块包括：有效期设置子模块，用于为锁设置有效期；其中，在有效期内，请求响应模块拦截到达第二应用端的交易请求；在锁失效后，请求响应模块受理到达第二应用端的交易请求。

根据本发明的实施例，其中，交易请求报文受到延迟使得查询请求报文比交易请求报文先到达第二应用端；查询请求报文抢锁成功，请求响应模块向第一应用端返回交易失败；在查询请求报文抢锁成功之后，交易请求报文到达第二应用端；交易请求报文抢锁失败，请求响应模块再次向第一应用端返回交易失败。

本发明通过设置锁装置和抢锁机制来以锁的方式进行控制，能够在网络延时的情况下，保证交易状态一致性，提高准确性；并且，与现有技术相比，能够避免由于不断的发起查询请求而导致交易处理时间延长的问题，因此缩短了交易处理时间；能够在应用出故障的情况下，有效缩短交易处理时间并保证交易状态一致性；能够在集群环境中某节点应用出故障的情况下，有效缩短交易处理时间并能有效保证交易状态一致性。通过哈希算法对业务字段计算得出锁值，能够提高唯一性。通过为锁值设置有效期，能够在有效期时间内保证交易的准确性。

附图说明

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

图1是正常情况下的现有交易方法的流程图；

图2是网络延迟情况下的现有交易方法的流程图；

图3是集群节点故障情况下(查询交易不存在返回失败)的现有交易方法的流程图；

图4是集群节点故障情况下(查询交易不存在返回未明)的现有交易方法的流程图；

图5是根据本发明实施例的网络交易方法的流程图；

图6是根据本发明实施例的集群节点故障情况下的网络交易方法的流程图；

图7是根据本发明实施例的网络延迟情况下的网络交易方法的流程图。

具体实施方式

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

如图5所示，根据本发明的实施例提供了一种网络交易方法，该网络交易方法包括以下步骤：

S52，第一应用依次向第二应用发送交易请求报文和查询请求报文。

S54，当交易请求报文和查询请求报文到达第二应用时都分别进行抢锁操作，其中，交易请求报文和查询请求报文之中后到达第二应用的一者抢锁失败。

其中，在交易请求报文抢锁成功的情况下，第二应用受理第一应用的交易请求；在交易请求报文抢锁失败的情况下，第二应用向第一应用返回交易失败。也就是说，在交易过程中，当交易请求报文到达时首先进行抢锁，如果成功则表示抢锁成功，处理正常逻辑；如果抢锁失败，则表示之前查询请求报文已经抢锁成功，则返回失败。正常情况下，交易请求报文在查询请求报文之前，流程应该是：交易请求报文抢锁成功，查询请求报文会抢锁失败，都按照正常流程处理。其他情况为查询请求报文比交易请求报文优先到达，可以使用本方案优化后的逻辑进行处理。

本发明的上述技术方案，通过设置锁装置和抢锁机制来以锁的方式进行控制，能够在网络延时的情况下，能保证交易状态一致性，提高了准确性。并且，与现有技术相比，能够避免由于不断的发起查询请求而导致交易处理时间延长的问题，因此缩短了交易处理时间。

在一个实施例中，在步骤S54处可包括以下步骤：

S541，交易请求报文受到延迟使得查询请求报文比交易请求报文先到达第二应用；

S542，查询请求报文抢锁成功，向第一应用返回交易失败；

S543，在查询请求报文抢锁成功之后，交易请求报文到达第二应用；

S544，交易请求报文抢锁失败，再次向第一应用返回交易失败。

在一个具体实施例中，如图6所示，在集群环境某个节点出故障的场景下，A应用(即第一应用)发出的查询请求报文先于交易请求报文到达B应用(即第二应用)，B应用中查询请求报文优先抢锁成功，查询流程中以失败状态返回给A应用，当交易请求报文达到时，抢锁失败，则以失败状态返回给A应用,这样就保证了状态的一致性了。

在另一个具体实施例中，如图7所示，在网络延迟的场景下，查询请求报文比交易请求报文先到达B应用，此时因为交易请求报文根本没有到达B应用，在查询流程中会查询出交易不存在，如图7中的步骤6，查询请求报文进行抢锁成功，则在查询流程中准确的判断出了查询请求报文先于交易请求报文到达B应用，从而返回查询请求报文先于交易请求报文到达系统，以失败状态返回。当延迟的交易请求报文到达B应用时，交易抢锁失败，则以失败的状态返回，最终保证了A应用与B应用之间的状态一致性。

在一个实施例中，在步骤S54(图5)处进行抢锁操作之前还可以包括：生成锁的锁值的步骤。其中，锁值是通过哈希算法对交易请求报文和查询请求报文的共有字段进行计算得到的。具体的，可通过SHA-256哈希算法将交易请求报文和查询请求报文共有字段(例如：卡号，双方唯一流水等)结合在一起计算出锁值，从而可保证锁值唯一性。

在锁值存储方面：如果应用是单机部署，那么可以使用本地存储、中间件(redis、kafka)存储、数据库存储等。如果应用是集群环境多节点部署，那么锁值必须使用集中存储，以保证集群环境中每个节点的每笔交易共享一把锁值。

另外，在生成锁的锁值的步骤中可以包括：为锁设置有效期。其中，在有效期内，拦截到达第二应用的交易请求；在锁失效后，受理到达第二应用的交易请求。具体来说，在生成锁值过程中，可给锁设置有效期，一般交易隔天都需要进行对账，一般设置为2天。具体需结合业务场景设置不同值。过了有效期锁值失效。严格来说锁值不用释放，但是结合业务场景和存储空间利用，可以释放锁值，但尽可能保证原始交易在锁失效后不会再请求上来，例如查询请求报文先于付款交易到达这种场景，查询请求报文到达时设置了锁值，在锁生效期间，交易上来都会拦截掉，锁失效后，如果交易上来会继续受理。所以需结合具体场景设置一个有效期，在有效期失效之后能确定原始交易不会再上送。在实际应用中，付款交易设置的有效期可以是7天，从业务场景判断7天之后确定不会有原始交易上送上来。

根据本发明的实施例，还提供了一种网络交易装置，该网络交易装置包括第一应用端和第二应用端。第一应用端包括请求发送模块，用于依次向第二应用端发送交易请求报文和查询请求报文，其中，交易请求报文和查询请求报文到达第二应用端时都分别进行抢锁操作，交易请求报文和查询请求报文之中后到达第二应用端的一者抢锁失败。

其中，第二应用端包括请求响应模块，用于在交易请求报文抢锁成功的情况下，受理第一应用端的交易请求，还用于在交易请求报文抢锁失败的情况下，向第一应用端返回交易失败。

在一个实施例中，第二应用端还包括锁生成模块。锁生成模块用于生成锁的锁值；其中，锁值是通过哈希算法对交易请求报文和查询请求报文的共有字段进行计算得到的。

在一个实施例中，锁生成模块包括有效期设置子模块。有效期设置子模块用于为锁设置有效期。其中，在有效期内，请求响应模块拦截到达第二应用端的交易请求；在锁失效后，请求响应模块受理到达第二应用端的交易请求。

在一个实施例中，交易请求报文受到延迟使得查询请求报文比交易请求报文先到达第二应用端；查询请求报文抢锁成功，请求响应模块向第一应用端返回交易失败；在查询请求报文抢锁成功之后，交易请求报文到达第二应用端；交易请求报文抢锁失败，请求响应模块再次向第一应用端返回交易失败。

综上所述，借助于本发明的上述技术方案，通过设置锁装置和抢锁机制来以锁的方式进行控制，能够在网络延时的情况下，保证交易状态一致性，提高准确性；能够在应用出故障的情况下，有效缩短交易处理时间并保证交易状态一致性；能够在集群环境中某节点应用出故障的情况下，有效缩短交易处理时间并能有效保证交易状态一致性。通过哈希算法对业务字段计算得出锁值，能够提高唯一性。通过为锁值设置有效期，能够在有效期时间内保证交易的准确性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种网络交易方法，其特征在于，包括：

第一应用依次向第二应用发送交易请求报文和查询请求报文；

当所述交易请求报文和所述查询请求报文到达所述第二应用时都分别进行抢锁操作，其中，所述交易请求报文和所述查询请求报文之中后到达所述第二应用的一者抢锁失败；

其中，在所述交易请求报文抢锁成功的情况下，所述第二应用受理所述第一应用的交易请求；在所述交易请求报文抢锁失败的情况下，所述第二应用向所述第一应用返回交易失败；

当所述交易请求报文和所述查询请求报文到达所述第二应用时都分别进行抢锁操作包括：

所述交易请求报文受到延迟使得所述查询请求报文比所述交易请求报文先到达所述第二应用；

所述查询请求报文抢锁成功，向所述第一应用返回交易失败；

在所述查询请求报文抢锁成功之后，所述交易请求报文到达所述第二应用；

所述交易请求报文抢锁失败，再次向所述第一应用返回交易失败。

2.根据权利要求1所述的网络交易方法，其特征在于，在进行所述抢锁操作之前还包括：

生成所述锁的锁值，其中，所述锁值是通过哈希算法对所述交易请求报文和所述查询请求报文的共有字段进行计算得到的。

3.根据权利要求2所述的网络交易方法，其特征在于，生成所述锁的锁值包括：

为所述锁设置有效期；

其中，在所述有效期内，拦截到达所述第二应用的交易请求；在所述锁失效后，受理到达所述第二应用的交易请求。

4.一种网络交易装置，其特征在于，包括第一应用端和第二应用端，

所述第一应用端包括请求发送模块，用于依次向所述第二应用端发送交易请求报文和查询请求报文，其中，所述交易请求报文和所述查询请求报文到达所述第二应用端时都分别进行抢锁操作，所述交易请求报文和所述查询请求报文之中后到达所述第二应用端的一者抢锁失败；

所述第二应用端包括请求响应模块，用于在所述交易请求报文抢锁成功的情况下，受理所述第一应用端的交易请求，还用于在所述交易请求报文抢锁失败的情况下，向所述第一应用端返回交易失败；

其中，所述交易请求报文受到延迟使得所述查询请求报文比所述交易请求报文先到达所述第二应用端；

所述查询请求报文抢锁成功，所述请求响应模块向所述第一应用端返回交易失败；

在所述查询请求报文抢锁成功之后，所述交易请求报文到达所述第二应用端；

所述交易请求报文抢锁失败，所述请求响应模块再次向所述第一应用端返回交易失败。

5.根据权利要求4所述的网络交易装置，其特征在于，所述第二应用端还包括：

锁生成模块，用于生成所述锁的锁值；其中，所述锁值是通过哈希算法对所述交易请求报文和所述查询请求报文的共有字段进行计算得到的。

6.根据权利要求5所述的网络交易装置，其特征在于，所述锁生成模块包括：

有效期设置子模块，用于为所述锁设置有效期；

其中，在所述有效期内，所述请求响应模块拦截到达所述第二应用端的交易请求；在所述锁失效后，所述请求响应模块受理到达所述第二应用端的交易请求。

Images