[发明专利]一种解决分布式应用交易后发先至的方法、装置及存储介质

说明书

本发明涉及信息技术领域，具体的提供了一种解决分布式应用交易后发先至的方法、装置及存储介质。本发明的目的在于解决分布式系统后发先至，造成业务错误的问题。未解决上述技术问题，主要方案包括，当渠道端发起一笔包含唯一字段的交易请求时，通过同一事务将交易流水表T1和查证表T2插入唯一字段，分布式应用系统根据交易流水表执行后续业务逻辑后将执行结果更新到查证表T2以供渠道端进行查证，当渠道端通过唯一字段查证时，无法在表T2中找到唯一字段对应的数据时，则将唯一字段和执行结果“失败”插入表T2，当堵塞结束，通过同一事务插入表T1、表T2时，因为T2表中唯一主键已经存在，因此插入表T1和表T2将失败，即交易请求失败。

技术领域

本发明涉及信息技术领域，具体的提供了一种解决分布式应用交易后发先至的方法、装置及存储介质。

背景技术

本技术主要应用于互联网分布式微服务架构领域，作为服务提供方，基本上都是多机器部署，由于网络或机器资源问题，可能出现消费方后发的请求在服务提供方先处理的情况，如果系统处理不当，势必会带来一定影响，通过该技术能解决在分布式应用中出现交易后发先至带来的问题，确保消费方能获取到准确的交易结果。

目前银行与各大互联网流量平台合作，通过API方式对接，银行主要负责底层产品输出，渠道负责前端展示销售。大部分渠道都是将交易数据缓存下来，客户查看时展示本地数据，减少与银行之间的频繁交互，提升客户体验。

就一笔购买交易而言，银行需要提供两个接口，一个购买，一个查证，目前渠道的做法是，首先调用购买接口，若接口超时，再定时通过原流水号调用查证接口来获取该交易的最终状态，从而达到与银行交易状态一致的目的。银行作为服务提供方，如果同一交易流水号查证接口先收到并处理，再接收到购买请求，这样查证接口由于未查到原交易返回失败，而实际购买交易处理又成功了，导致渠道本地记录的交易状态与银行不一致的问题。

这种查证比交易先到的问题，我们称之为后发先至，当前渠道的解决方案主要是两种：一是渠道交易请求发出后10分钟(可配置)之后再进行查证，前提是认为交易请求不可能10分钟之后再收到，二是在查证接口中对于未收到交易请求的流水号返回特殊错误码，渠道对于该错误码仍继续查证，若超过2小时查证回来还是这个错误码，就置失败处理。这两种方案都不能完美解决问题，在极端情况下还是会有双方状态不一致的风险。

为方便理解技术问题，现在做如下举例：

渠道方发送一个包含唯一交易流水号N的交易请求S给分布式应用，在分布式应用中，其中一个应用节点A接收到请求后，如果这个应用节点A出现堵塞，渠道方发送的这笔交易请求的数据将无法得到处理，也就不会写入分布式应用的交易流水表中，当渠道方发送的请求处理超时后，渠道方间隔固定时间后，会向分布式应用发起一个包含交易流水号N的查证请求，确认交易处理状态，此时分布式应用节点B接收到请求后，在交易流水表中根据交易流水号N进行查找数据，因为在分布式流水中的交易流水表中查不到该交易流水号N，则分布式应用会向渠道方返回“失败”，那面当应用接点A堵塞结束，继续完成了交易请求S，那么在分布式应用内的交易请求S的处理状态实际则为“成功”，然后返回给渠道的查证结果是“失败”，这就会导致后发先至，造成业务错误。

值得注意的是，当渠道端发起一条包含唯一主键(流水号)的查证时，如果在分布式微服务应用中无法通过唯一主键查找到相应的数据，其可能存在2种情况，一是、该唯一主键(流水号)对应的交易可能是不存在的，此时可返回查证结果“失败”，二是，该唯一主键(流水号)对应的交易可能因为堵塞，还未写入，但是这笔交易却是实际存在的，此时如果返回查证结果“失败”则会与实际情况相悖，因为当堵塞消失，这笔交易很大可能会是执行“成功”，而查证返回的是“失败”，这与实际情况相悖了，造成业务错误。

发明内容

本发明的目的在于解决分布式系统后发先至，造成业务错误的问题。

为了解决上述技术问题，本发明采用以下技术手段：