CN116069789A - 一种数据查询方法、装置以及计算机可读存储介质 - Google Patents

Abstract

本申请实施例公开了一种数据查询方法、装置以及计算机可读存储介质，该数据查询方法包括：调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的；若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象；根据第一数据对象确定对应的第一业务交易的支付结果。通过本申请实施例，可以降低查询支付结果的逻辑复杂度，进而有效提高获取支付结果的效率。

Description

一种数据查询方法、装置以及计算机可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据查询方法、装置以及计算机可读存储介质。

背景技术

随着互联网时代高速发展，各种商业行为进行了数字化和信息化的巨大演变，造就了如今的电子商务，各类电子商务经营活动离不开支付系统对业务系统中产生的各种交易行为的管理。

通常在实际的互联网应用中，出于对交易安全性的考虑，不论是何种形式的支付情况，在调用第三方支付渠道(简称支付渠道)后，业务系统均需要获取支付的结果，对支付结果的查询是必要的。在这个过程中，不仅要考虑支付渠道的回调，还要考虑主动查询支付渠道获取支付结果，而传统采用数据库轮询方式，或者进入其他中间组件的方式，会增加代码的复杂度，以及对数据库资源的浪费。为此，有必要提出一种简洁高效的方式获取支付结果。

发明内容

本申请实施例提供一种数据查询方法、装置以及计算机可读存储介质，可以降低查询支付结果的逻辑复杂度，进而有效提高获取支付结果的效率。

本申请实施例一方面提供了一种数据查询方法，包括：

调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的；

若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象；

根据第一数据对象确定对应的第一业务交易的支付结果。

本申请实施例一方面提供了一种数据查询装置，包括：

调用模块，用于调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的；

确定模块，用于若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象；

确定模块，还用于根据第一数据对象确定对应的第一业务交易的支付结果。

本申请实施例一方面提供了一种计算机设备，包括：处理器和存储器；

存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行本申请实施例中的方法。

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

相应的，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例中一方面提供的方法。

在本申请实施例中，通过调用数据存储线程将业务交易对应的数据对象写入目标存储系统中，调用数据查询线程在目标存储系统中查询并确定数据对象，依据数据对象进行业务交易的支付结果的查询，整个过程只需调用两种功能性的线程实现支付结果的查询，降低了支付结果查询的逻辑复杂度，进而有效提高获取支付结果的效率。

附图说明

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

图1是本申请实施例提供的一种数据查询系统的架构图；

图2是本申请实施例提供的一种数据查询相关的服务调用的示意图；

图3是本申请实施例提供的一种数据查询方法的流程示意图；

图4是本申请实施例提供的另一种数据查询方法的流程示意图；

图5是本申请实施例提供的又一种数据查询方法的流程示意图；

图6是本申请实施例提供的一种数据查询装置的结构示意图；

图7是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

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

为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。

Redis：一个高性能key-value存储系统，支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，运行时数据存储在内存中，并提供多种语言的API(ApplicationProgramming Interface，应用程序接口)的非关系型数据库。在现今互联网项目中，Redis普遍应用于缓存技术中，即将数据库中经常访问的热点数据存入Redis中。

Mysql：一个关系型数据库管理系统，是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样可以增加数据读取速度，并提高数据存储的灵活性。

Message Queue：消息队列MQ，通过将要传输的数据消息放在队列中，使用队列机制来实现消息传递。

RocketMQ：一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，属于分布式、队列模型的开源消息中间件，适用于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。

异步处理：指发出一个请求后，不需要等待返回，随时可以触发下一个请求。

线程池：一种多线程处理形式，处理过程中可以将任务添加到队列中，然后在创建线程后自动启动这些任务。

下面将结合附图，对本申请实施例提供的数据查询系统的架构图进行介绍。

请参见图1，图1是本申请实施例提供的一种示例性地数据查询系统的架构图。如图1所示，该架构图包括数据查询设备101、目标存储设备102、第三方支付设备103以及目标数据库104。

其中，数据查询设备101中可以部署多个功能系统，例如业务系统、支付系统。具体可以是在数据查询设备101调用第三方支付设备103的支付接口后，将携带全局唯一的业务编号的数据对象存入目标存储设备102中，数据查询设备101按照相应的规则进行支付结果的查询。可选地，可以在数据查询设备101中通过计算机编程语言(如JAVA语言)开启2个线程池，用于分别管理数据存储线程和数据查询线程，其中数据存储线程负责将提交支付请求后需要获取支付结果的业务交易所对应的数据对象写入目标存储设备102中，数据查询线程则负责对目标存储设备102中存在的业务交易所对应的数据对象进行查询，然后根据获取到的数据对象在第三方支付设备103中获取支付结果，即进行相应的第三方支付渠道的调用，获取支付结果，接着将获取到的支付结果写入目标数据库104中，并删除目标存储设备102中相应的数据对象。

需要说明的是，数据查询线程在轮询到目标存储设备102中未存在需要查询支付结果的数据对象时，可以通过对应线程提供的API，对数据查询线程进行阻塞，释放出资源。当目标存储设备102中存入需要获取支付结果的数据对象时，数据存储线程会把该数据对象写入目标存储设备102中，并唤醒数据查询线程，进行支付结果的查询。通过目标存储设备102中数据对象的有无，可以对数据查询线程进行阻塞或唤醒处理，进而可以避免数据查询线程在没有未处理的业务交易的情况下查询支付结果，减轻数据库的访问压力，缓解程序空转的情况。此外，本申请实施例中所提及的“支付渠道”和“第三方支付渠道”在不强调其区别时，表示的是相同的含义，可以混合使用。

目标存储设备102中可以用于存储需要获取支付结果的业务交易相关的数据，具体以数据对象的形式存在，该数据对象可以包括支付订单标识、支付渠道标识、延迟查询时间等。可选地，目标存储设备可以是Redis集群，数据对象可以是封装好的一个Java对象，具体存储在Redis的ZSET数据结构中。上述通过利用自身的抗并发能力以及超高效率的Redis组件为介质，可以实现对业务交易的支付结果的查询。

第三方支付设备103是第三方支付渠道的后台设备。所谓第三方支付渠道可以是指通过银联或网联对接，连接交易双方进行网络交易的平台。例如各大银行的银联、各种手机支付(例如手机内置的支付应用)、以及第三方公司研发的支持支付业务的应用等。第三方支付设备设置有支付接口和查询接口，其中支付接口用于提供给需要进行业务交易的设备进行调用，例如数据查询设备可以调用支付接口实现业务交易的订单支付，查询接口用于给需要获取支付结果的设备进行调用，例如数据查询设备101可以通过目标存储设备102中的数据对象，调用第三方支付设备的查询接口获取对应业务交易的支付结果。需要说明的是，第三方支付设备103可以包括多个不同支付平台的后台设备，具体在获取支付结果时调用的第三方支付设备可以根据数据对象中的支付渠道标识来确定。

目标数据库104可以用于存储交易订单数据，该交易订单数据可以包括支付订单号、支付渠道信息以及指示该交易订单支付成功或支付失败的支付结果。可选地，在调用第三方支付设备查询交易订单的支付结果满足条件时，可以通过数据查询线程将支付结果以及目标存储设备102中相关数据对象的信息更新至目标数据库104中。可选地，目标数据库104可以是关系型数据库，例如MySQL。

可以理解的是，数据查询设备101可以安装于终端设备中，也可以安装于服务器中，在此不做限制。其中，终端设备可以是智能手机、平板电脑、智能可穿戴设备、个人电脑、智能交互设备、智能车载设备等等设备，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

可以发现，上述数据查询系统的架构图不需要引入消息中间件，避免了对消息中间间进行额外的维护，减轻了维护成本；功能逻辑简单，可以实现高效地支付结果查询。

基于该数据查询系统的架构图，更详细地软件层面各系统的调用可以参见图2示出的一种数据查询相关的服务调用的示意图，如图2所示，包括多个业务系统(包括201A、201B、201C)、支付系统202、多个第三方支付平台(包括203A、203B)、目标存储系统204以及数据库205。

其中，业务系统201A、业务系统201B以及业务系统201C可以是同一应用中的不同功能的业务系统，上述任一个业务系统和支付系统202可以组成同一个应用中的不同功能模块。以在线购物平台为例，业务系统主要实现的是平台用户注册、商品定价、营销活动等相关功能，而支付系统202则是支撑业务系统进行交易的模块，通过和第三方支付渠道(即图2示出的第三方支付平台203A和第三方支付平台203B)进行通信，对业务交易产生的交易订单进行处理。通常业务系统会将用户购买行为通过各种交易订单的形式进行记录，并交付支付系统202进行处理，最终由支付系统202完成收款与付款。

第三方支付平台203A和第三方支付平台203B属于不同的第三方支付渠道，通过支付系统202和第三方支付平台的对接，可以进行业务的交易。从用户层面来说，第三方支付渠道是支付系统所支持的具体支付方式。可选地，为用户提供的第三方支付渠道可以包括至少一个，以供用户选择合适的支付渠道进行业务的交易。可选地，支付系统在接收并响应于用户的选择指令之后，根据选择指令中携带的支付渠道标识调用目标支付渠道，在成功调用之后，将对应业务交易的订单数据(即数据对象)存储到固定的目标存储系统204中，该订单数据包括业务单号(即支付订单标识)，除此之外，还包括支付渠道标识以及延迟查询时间均可以存储到该目标存储系统204中。其中，延迟查询时间是用于指定支付结果查询的一个预设时间，目标存储系统204诸如是Redis集群。

通过目标存储系统204中存储的订单数据包括的支付渠道标识以及支付订单标识，可以回查具体的支付渠道，获取业务交易的支付结果，然后可以将目标存储系统204中的相关数据更新到数据库205中，以及指示支付状态的支付结果更新到数据库205中。

上述服务调用的过程中，通过目标存储系统204可以实现消息中间件的功能，即对数据进行生产和消费，并且在数据消费速度跟不上生产速度的时候，通过将需要查询支付结果的数据对象存储在目标存储系统中，等待消费即可，这样原有的数据库不会因为突发的超负荷请求而崩溃，防止轮询对数据的频繁查询，进而减轻数据库的访问压力。整个过程不需要部署消息中间件，避免了占用更多服务器资源环境，以及消耗更多人力成本进行维护，并且在目标存储系统使用Redis集群时，由于使用Redis自身的容错机制，如集群部署，数据持久化等机制，可以对保证需要获取支付结果的数据不会丢失，造成无法获取支付结果的情况，并且由于Redis超高的性能支持，支付结果获取的实时性也可以得到有效地保证。

进一步地，为便于理解，请参见图3，图3是本申请实施例提供的一种数据查询方法的流程示意图。该数据查询方法可以由计算机设备(如上述图1中的数据查询设备)执行，该数据查询方法包括但不限于以下步骤：

S301，调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果。

在本申请实施例中，每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的。

在调用数据查询线程之前，可以调用数据存储线程将数据对象存储到目标存储系统中，也可以是在数据查询线程查询的同时，调用数据存储线程将数据对象存储在目标存储系统中。针对每笔业务交易，数据查询设备可以根据用户选择的支付方式或者自动关联的支付方式向第三方支付渠道发起支付请求，当第三方支付渠道调用成功时，认为支付请求提交成功，此时可以通过调用数据存储线程将数据对象存储到目标存储系统中。在一些情况下，例如该笔业务交易的支付结果为支付成功，可能由于网络卡顿或设备等一些客观因素导致没有及时查询到支付结果，使得用户再次发起支付，对应的支付请求是失败的，第三方支付渠道不会被成功调用，而是直接返回数据查询设备的支付系统。

目标存储系统是用于存储数据对象的工具，支持存储海量的数据对象。优选地，该目标存储系统可以是高性能的Redis数据库，也可以是其他支持高并发数据写入和查询的存储系统，在此不做限制。以Redis为例，由于其不仅仅支持简单的key-value类型的数据，同时还提供list、set、zset、hash等数据结构的存储，本实施例中的数据对象具体可以存储在Redis的zset数据结构中，通过zset构造延迟队列，实现消息中间件的功能。并且由于Redis的高性能特性，可以有效提高数据查询的吞吐量，减轻数据库的访问压力，此外，由于Redis自身的容错机制，例如集群部署，即使某个存储设备宕机，也不会造成整个系统无法主动获取支付结果的情况，进而提升整个系统的鲁棒性。数据存储线程和数据查询线程可以是不同线程池管理的线程，可以通过计算机编程语言(如Java语言)部署在数据查询设备的支付系统中。

需要说明的是，这里采用线程池进行数据对象的存储和读取可以有效提高系统的运行效率，降低系统运行的压力，并进一步提升支付结果获取的效率。这是由于线程池可以根据系统的需求和硬件环境灵活的控制线程的数量，且可以对所有线程进行统一的管理和控制。

在本申请实施例中，数据查询线程查询所得到的查询结果用于指示目标存储系统中是否存在数据对象，查询结果包括两种：①若查询结果指示目标存储系统中存在数据对象，可以参见下述步骤S302～S303的步骤进行相应处理。②若查询结果指示目标存储系统中不存在数据对象，则对数据查询线程进行阻塞处理。在目标存储系统中没有带查询支付结果的数据对象时，对数据查询线程进行阻塞处理，可以释放出资源，从而减少对系统资源不必要消耗，后续在数据存储线程在目标存储系统中再次存入数据对象时，可以自动唤醒数据查询线程，执行步骤S302～S303的内容。需要说明的是，为了保证资源的不必要浪费，利用对目标存储系统查询所得到的查询结果进一步指示后续的处理是必要的。

S302，若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象。

本申请实施例中，数据对象包括延迟查询时间，这里的延迟查询时间是指调用数据查询线程查询数据对象对应业务交易的支付结果的时间，具体是一个时间点，例如10:00:03，对于延迟查询时间，可以精确到秒，也可以精确到毫秒。当目标存储系统中只包括一个数据对象时，该数据对象即第一数据对象，当目标存储系统中包括两个及以上数据对象，可以按照延迟查询时间的先后确定先被处理的数据对象。

可选地，确定第一数据对象的方式可以是：比较目标存储系统中各个数据对象包括的延迟查询时间；将目标存储系统中包括的延迟查询时间最小的数据对象确定为第一数据对象。通过比较各个数据对象包括的延迟查询时间的大小，将包括延迟查询时间最小(也即将延迟查询时间最早)的数据对象确定为第一数据对象，进而后续对第一数据对象进行处理。类似于队列先进先出的规则，将存储在目标存储系统中的数据对象视为队列，该队列以延迟查询时间的早晚作为进出队列的标准，这样可以使得最先需要处理的数据对象被及时地处理，进而有序提高支付结果的获取效率。需要说明的是，如果多个数据对象的延迟查询时间是相同的，则可以从中随机确定一个数据对象，将其作为第一数据对象并进行后续处理。或者是针对多个延迟查询时间满足条件的数据对象均可以作为第一数据对象，并同时启用多个数据查询线程根据第一数据对象确定对应第一业务交易的支付结果。

S303，根据第一数据对象确定对应的第一业务交易的支付结果。

在一实施例中，由于每个数据对象和业务交易一一对应，该业务交易具体可以是一笔交易订单或者说支付订单，针对不同的数据对象，所对应的业务交易是不同的，因此，数据对象具有唯一性。具体可以通过数据对象包括的支付订单标识体现的。业务交易的相关数据，包括延迟查询时间、支付渠道标识、支付订单标识均封装在数据对象中。第一数据对象除了包括延迟查询时间，还可以包括支付渠道标识和支付订单标识。其中支付订单标识通过数值表示，具体为支付订单号，支付渠道标识可以用于指示支付渠道信息，该支付渠道标识对于不同的第三方支付渠道来说具有唯一性，但是对于不同的数据对象来说可能是相同的，例如数据对象A和数据对象B中的支付渠道标识都指示的是支付渠道C。第一业务交易是待查询支付结果的业务交易，具体可以是第一数据对象对应的交易订单。

可选地，第一业务交易的支付结果的确定方式可以为：若第一数据对象包括的延迟查询时间小于或等于当前时间，则根据第一数据对象包括的支付渠道标识确定目标支付渠道；调用目标支付渠道的查询接口，根据第一数据对象包括的支付订单标识获取对应的第一业务交易的支付结果。

也就是说，在调用第三方支付渠道查询接口获取支付结果之前，第一数据对象包括的延迟查询时间需要和当前时间进行比较，以确定当前时间是否达到预设的支付结果查询时间。这里的当前时间和延迟查询时间可以是时间点，举例来说，当前时间为10:00:03，延迟查询时间为10:00:05，当前时间并没有达到延迟查询时间，数据查询线程将不会调用第三方支付渠道的查询接口查询支付结果，反之，在当前时间达到延迟查询时间的时候，也就是当前时间大于或等于延迟查询时间，数据查询线程可以根据第一数据对象中存储的信息，包括支付渠道标识和支付订单标识，对第一业务交易的支付结果进行查询。具体地，可以是先根据支付渠道标识确定相应的目标支付渠道，在确定目标支付渠道之后，可以带上支付订单标识调用目标支付渠道的所提供的查询接口，根据支付订单标识在第三方支付渠道查询对应第一业务交易的支付结果，进而获取用户是否已经支付该第一业务交易的结果。

上述确定第一数据对象的方式，通过延迟查询时间决定数据查询线程是否调用第三方支付渠道的查询接口进行查询，可以避免数据查询线程在没有支付结果时也去调用第三方支付渠道的查询接口，这样可以降低数据查询线程空转的概率，从而高效地利用系统资源进行支付结果的查询。需要说明的是，上述确定第一业务交易的支付结果的实现方式也可以应用于目标存储系统中剩余数据对象对应的业务交易的支付结果查询，即在每次处理时根据延迟查询时间确定一数据对象，进而采用相同的方式查询到该数据对象对应业务交易的支付结果。这样可以确定出目标存储系统中存储的所有数据对象对应业务交易的支付结果，该支付结果用于指示业务交易是何种支付状态。该支付状态可以包括支付成功、支付失败、待支付。根据不同的支付结果可以对数据对象进行相应的更新或删除处理。具体可以参见图4对应实施例的内容，在此先不做详述。

需要说明的是，本实施例中的数据查询线程和数据存储线程可以通过相应的程序设计实现，例如Java程序，通过相应的程序设计可以更加方便开发人员对整个系统(例如前述提及的业务系统、支付系统、目标存储系统等)的控制，以及项目资源的合理分配。尤其是在没有支付业务产生时，数据查询线程会被阻塞，这样不会造成服务器和数据库的资源浪费。

综上所述，本实施例至少具有以下优点：

通过调用数据查询线程对目标存储系统中是否存在数据对象进行查询，可以在没有数据对象时释放相应资源，避免不必要的资源占用，而针对存在数据对象的情况下，将利用数据查询线程对数据对象对应的业务交易的支付结果进行查询，对目标存储系统中数据对象的处理顺序可以依据延迟查询时间的大小来进行，并且该延迟查询时间还可以是决定数据查询线程是否调用支付渠道获取支付结果。通过这两个条件的设置，包括是否存在数据对象、当前时间是否达到延迟时间，可以最大化节约设备资源和计算资源来启用数据查询线程，进而高效地确定出对应业务交易的支付结果。

进一步地，为便于理解，请参见图4，图4是本申请实施例提供的另一种数据查询方法的流程示意图。该数据查询方法可以由计算机设备(如上述图1中的数据查询设备)执行，该数据查询方法包括但不限于以下步骤：

S401，当第二业务交易对应的支付请求提交成功时，生成支付请求对应的第二数据对象。

在一实施例中，第二业务交易是当前正在向第三方支付渠道提交支付请求的交易。可选地，针对第二业务交易对应的支付请求提交成功的判断可以采用如下方式：根据接收到第二业务交易对应的支付请求包括的支付渠道标识，从提供的一个或多个支付渠道中确定目标支付渠道；调用目标支付渠道的支付接口；当接收到目标支付渠道发送的成功调用的通知消息时，确定支付请求提交成功。由于支付系统可以为用户提供至少一个支付渠道进行选择，也可以是支付系统自动关联某个固定的支付渠道进行业务交易的支付，无论是何种，最终都会有一个确定的支付渠道，即目标支付渠道的支付接口被调用，以完成对应业务交易的支付。当支付系统接收到通知消息是指示该目标支付渠道成功调用，则表明支付请求提交成功。以用户使用在线购物平台购买商品进行示例性说明，用户点击结算会生成一笔交易订单，在选择支付渠道并点击提交订单之后，跳转到第三方支付渠道提示用户输入支付密码的界面，到这一步即表示支付系统向第三方支付渠道提交支付请求成功，该笔交易订单即第二业务交易。在支付请求提交成功之后可以在支付系统中生成对应的第二数据对象。

进一步地，生成支付请求对应的第二数据对象可以是：获取第二业务交易对应的支付请求提交成功时的参考时间戳，支付请求包括支付渠道标识和支付订单标识；根据参考时间戳和预设时长生成延迟查询时间；根据延迟查询时间、支付渠道标识和支付订单标识生成支付请求对应的第二数据对象。其中，第二业务交易的支付请求提交成功的参考时间戳可以作为起始时间点，将该起始时间点加上预设时长即可作为延迟查询时间，预设时长属于延迟查询的时间信息，时间范围可以在3～5秒，该预设时长是给用户支付动作的操作时间，也即预计用户在预设时长的时间内完成支付操作，例如前述示例中在输入支付密码的界面输入密码。举例来说，若支付请求提交成功的参考时间戳为10:00:00，预设时长为5秒，则根据参考时间戳和预设时长生成的延迟查询时间为10:00:05。与此同时，支付请求中包括的支付渠道标识可以是系统自动关联的第三方支付渠道生成的，也可以是根据用户从多个支付渠道选择目标支付渠道生成的；支付请求中包括的支付订单标识可以是支付订单号，具体可以由支付系统自动生成。在向第三方支付渠道提交支付请求成功之后，支付系统可以将以上的支付订单标识、支付渠道标识、延迟查询时间封装为第二数据对象。

S402，调用数据存储线程将第二数据对象存储至目标存储系统中，并唤醒数据查询线程。

在一实施例中，数据存储线程可以将上述封装好的第二数据对象存储到目标存储系统中，对于不同业务交易的支付请求提交成功时所产生的数据信息，包括延迟查询时间、支付订单标识、支付渠道标识，均可以按照步骤S401中生成第二数据对象的方式，生成业务交易对应的数据对象，进而存储到目标存储系统中。对于数据查询线程的唤醒时机，可以是将第一个数据对象存储到目标存储系统时唤醒，也可以是在唤醒之前：判断数据查询线程是否处于阻塞状态，若是，则唤醒数据查询线程，若否，则维持数据查询线程的现有状态。这是因为调用数据存储线程存储的数据对象和数据查询线程处理的数据对象不一定是同步的，数据查询线程可能也不是首次启用。举例来说，当数据查询线程将目标存储系统中所有的数据对象都处理完毕，并且得到的支付结果都是支付成功，根据下述支付结果的相应处理，此时目标存储系统中不存在数据对象，同时也没有新的数据对象存入，按照前述实施例的说明，数据查询线程会被阻塞。那么在一段时间之后，新的数据对象进入目标存储系统，此时则需要唤醒数据查询线程，获取相应的数据对象进行处理。需要说明的是，如果数据存储线程一直在存储数据对象，可以根据数据对象的数量唤醒匹配数量的数据查询线程，进行后续的处理。这里的匹配数量可以是数据对象和数据查询线程成比例的数量，或者是一一对应。

需要说明的是，步骤S401～S402在S403等步骤之前的这种执行顺序仅作为一种示例，但并不一定是必须的，在执行数据查询线程查询数据对象之前或者之后或者同时，均可以调用数据存储线程存储数据对象。

S403，调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果。

S404，若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象。

S405，根据第一数据对象确定对应的第一业务交易的支付结果。

上述步骤S403～S405可以参见前述实施例中的S301～S303，在此不做赘述。下述内容主要是对不同支付结果的处理进行相关阐述。

在一实施例中，若支付结果指示的支付状态为支付成功或支付失败，则调用数据查询线程将支付结果更新至目标数据库中，并将第一数据对象从目标存储系统中删除。也就是说，若第一业务交易已支付或者是已扣款但显示支付失败的支付结果，则数据查询线程在获取到支付结果之后，可以将目标存储系统中相应的第一数据对象进行删除，这样可以避免后续重复根据该数据对象查询相应的支付结果。同时可以将支付结果更新到目标数据库中，该目标数据库可以是关系型数据库，例如MySQL数据库，无论是支付成功或支付失败，目标数据库中记录的支付结果均可表示该笔业务交易已完成。

在另一实施例中，若支付结果指示的支付状态为待支付，则根据当前时间对目标存储系统中存储的第一数据对象包括的延迟查询时间进行更新处理；或者，根据第一数据对象生成第三数据对象，调用数据存储线程将第一数据对象从目标存储系统中删除，并将第三数据对象存储至目标存储系统中，第三数据对象包括的延迟查询时间是通过对第一数据对象包括的延迟查询时间进行更新处理得到的。也就是说，若第一业务交易为待支付的支付结果时，则说明该第一业务交易还未完成支付，需要再次设置一个预设的支付结果查询时间，即对第一数据对象原有的延迟查询时间进行更新处理，将原有的延迟查询时间进行变更，避免数据查询线程一直根据该数据对象查询对应的支付结果，造成无效地查询。这里延迟查询时间的更新可以是以获取到支付结果的时间点为起始时间点，加上预设时长来生成延迟查询时间。可选地，也可以是在原有的延迟查询时间的基础上加上预设倍数的预设时长，进而得到延迟查询时间，在此不做限制。上述支付结果为待支付时包括的两种处理方式：一种是直接将第一数据对象中的延迟查询时间替换为更新后的延迟查询时间，另一种是根据第一数据对象生成第三数据对象，该第三数据对象和第一数据对象的差别仅在于延迟查询时间的不同，后续可以调用数据存储线程将第三数据对象存到目标存储系统中，并将第一数据对象删除掉。两种方式均可以实现对延迟查询时间的更新，且数据对象都是在目标存储系统中，等待下一次查询对应业务交易的支付结果。

延迟查询时间在数据对象应用于首次查询对应的支付结果时，可以根据支付请求提交成功的参考时间和预设时长确定，但是数据对象不是应用于首次查询对应的支付结果时，延迟查询时间的确定可以根据获取支付结果的时间点和预设时长确定。也即，支付结果为待支付时，需要轮询该数据对象对应的支付结果，对应的延迟查询时间会相应变化，举例来说，假设用户A基于某一订单指定目标支付渠道，该目标支付渠道成功调用的时间为10点整，预设时长为5秒，那么支付结果第一次查询的时间则是10点0分5秒，但是在10点0分6秒时查询到相应的支付结果为待支付，此时需要将延迟查询时间进行调整，例如将延迟查询时间调整为10点0分11秒，这样在即需要在10点0分11秒之后通过数据查询线程调用第三方渠道的查询接口获取支付结果。通过延迟查询时间的设置，除了可以避免数据查询线程在没有支付结果时被调用，还可以有效避免支付结果为待支付有效设置数据查询线程调用的时机，从而有效地利用系统资源进行支付结果的查询。

需要说明的是，上述数据查询线程也可以称为支付结果查询线程，对于支付结果为待支付，除了调整延迟查询时间，还可以直接对数据查询线程进行等待时间的设置，例如将数据查询线程等待预设时间(例如15秒)之后再获取数据对象，执行支付结果的查询处理。

此外，应该理解的是，虽然图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

综上所述，本实施例至少具有以下优点：

在业务交易对应的支付请求提交成功时，将支付订单标识、支付渠道标识、延迟查询时间等封装为第二数据对象并存储到目标存储系统中，这样在根据数据对象确定对应业务交易的支付结果时，依次可以根据延迟查询时间、支付渠道标识、支付订单标识有序且高效地确定支付结果。此外，针对不同的支付结果，对于目标存储系统中的数据对象有相应地调整或删除等操作，这样可以避免查询过程中的重复查询，进一步提升支付结果查询的效率。

基于上述实施例所描述的内容，可以提供如图5示出的又一种数据查询的流程示意图。其中，以目标存储系统为Redis为例进行说明。

1)支付系统向第三方支付渠道提交支付请求成功之后，将支付订单号、支付渠道信息、延时查询时间封装为一个数据对象(例如Java对象)，通过调用数据存储线程将数据对象存储到Redis的ZSET数据结构中，与此同时，可以唤醒支付结果查询线程(即图5中的Java程序轮询线程)对支付结果进行查询。

2)在支付结果查询线程被唤醒之后，查询Redis中的数据对象。即Redis中有数据，则调用支付渠道，查询支付结果。具体地，首先获取数据对象中的延时查询时间，依据延迟查询时间确定出当前查询的数据对象，以及获取当前时间。通过比较当前时间和延时查询时间的大小，决定是否利用支付结果查询线程调用第三方支付渠道查询支付结果。在当前时间大于延时查询时间的条件下，支付结果查询线程才会根据获取到的数据对象中所存储的信息，即获取具体的第三方支付渠道以及支付订单号，调用第三方支付渠道所提供的查询接口，对该交易订单的支付结果进行查询，最终可以获取到用户是否支付该交易订单的结果，即支付结果。

3)当调用第三方渠道获取到的支付结果为“支付成功”时，支付结果查询线程可以将该交易订单的支付结果更新到支付系统的数据库存储的交易订单数据上，然后删除Redis中该笔交易订单对应的数据对象，也即对应的业务单号、支付渠道信息、延时查询时间信息等均可以被清理，这样可以避免重复查询。

4)当调用第三方渠道获取到的支付结果为“待支付”时，可以对Redis中存储的交易订单对应的数据对象中的延时查询时间进行更新，或者将原有的交易订单对应的数据对象删除，然后将携带更新后的延时查询时间的交易订单对应的数据对象重新写入Redis的ZSET数据结构中。这一过程可以由支付查询线程执行，也可以由数据存储线程或者其他线程执行，在此不作限制。

可以理解的是，本实施例中的支付单号、支付渠道信息、延时查询时间分别对应前述实施例中的支付订单标识、支付渠道标识、延迟查询时间；支付结果查询线程即为数据查询线程；交易订单对应业务交易。

在上述数据查询方案中，通过使用Redis实现了消息中间件队列的功能，可以解决了支付系统中对支付结果的异步获取的查询场景，而并未对项目引入新的中间件技术，减轻了项目维护成本。从整体上看，有以下优点：首先，功能逻辑简单，只需Redis不需要引消息中间件处理核销结果；其次，采用Redis缓存数据库能够减轻数据库的访问压力，防止轮询对数据的频繁查询，进而可以有效提升查询性能，并且由于Redis自身的容错机制，如集群部署，数据持久化等机制，可以对保证需要获取支付结果的数据不会丢失，造成无法获取支付结果的情况；再者，各种线程的使用可以通过程序设计自行调整，进而实现对系统以及项目资源进行灵活把控，并有效合理地利用服务器和数据库资源。

请参见图6，图6是本申请一个示例性实施例提供的一种数据查询装置的结构示意图。上述数据查询装置可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如该数据查询装置为一个应用软件；该数据查询装置可以用于执行本申请实施例提供的方法中的相应步骤。如图6所示，该数据查询装置60可以包括：调用模块601、确定模块602，其中：

调用模块601，用于调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的；

确定模块602，用于若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象；

确定模块602，还用于根据第一数据对象确定对应的第一业务交易的支付结果。

在一实施例中，该数据查询装置60还包括：生成模块603，其中：

生成模块603，用于当第二业务交易对应的支付请求提交成功时，生成支付请求对应的第二数据对象；

调用模块601，还用于调用数据存储线程将第二数据对象存储至目标存储系统中，并唤醒数据查询线程。

在一实施例中，生成模块603，具体用于：获取第二业务交易对应的支付请求提交成功时的参考时间戳，支付请求包括支付渠道标识和支付订单标识；根据参考时间戳和预设时长生成延迟查询时间；根据延迟查询时间、支付渠道标识和支付订单标识生成支付请求对应的第二数据对象。

在一实施例中，确定模块602，具体用于：比较目标存储系统中各个数据对象包括的延迟查询时间；将目标存储系统中包括的延迟查询时间最小的数据对象确定为第一数据对象。

在一实施例中，各个数据对象还包括支付订单标识和支付渠道标识，确定模块602，具体还用于：若第一数据对象包括的延迟查询时间小于或等于当前时间，则根据第一数据对象包括的支付渠道标识确定目标支付渠道；调用目标支付渠道的查询接口，根据第一数据对象包括的支付订单标识获取对应的第一业务交易的支付结果。

在一实施例中，数据查询装置60还包括更新模块604，用于：若支付结果指示的支付状态为支付成功或支付失败，则调用数据查询线程将支付结果更新至目标数据库中，并将第一数据对象从目标存储系统中删除。

在一实施例中，更新模块604，还用于：若支付结果指示的支付状态为待支付，则根据当前时间对目标存储系统中存储的第一数据对象包括的延迟查询时间进行更新处理；或者，根据第一数据对象生成第三数据对象，调用数据存储线程将第一数据对象从目标存储系统中删除，并将第三数据对象存储至目标存储系统中，第三数据对象包括的延迟查询时间是通过对第一数据对象包括的延迟查询时间进行更新处理得到的。

在一实施例中，数据查询装置60还包括阻塞模块605，用于：若查询结果指示目标存储系统中不存在数据对象，则对数据查询线程进行阻塞处理。

可以理解的是，本申请实施例所描述的数据查询装置60的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

请参见图7，图7是本申请实施例提供的一种计算机设备的结构示意图。该计算机设备70可以包含独立设备(例如服务器、节点、终端等等中的一个或者多个)，也可以包含独立设备内部的部件(例如芯片、软件模块或者硬件模块等)。该计算机设备70可以包括至少一个处理器701和通信接口702，进一步可选地，计算机设备70还可以包括至少一个存储器703和总线704。其中，处理器701、通信接口702和存储器703通过总线704相连。

其中，处理器701是进行算术运算和/或逻辑运算的模块，具体可以是中央处理器(central processing unit，CPU)、图片处理器(graphics processing unit，GPU)、微处理器(microprocessor unit，MPU)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)、复杂可编程逻辑器件(Complex programmable logic device，CPLD)、协处理器(协助中央处理器完成相应处理和应用)、微控制单元(Microcontroller Unit，MCU)等处理模块中的一种或者多种的组合。

通信接口702可以用于为所述至少一个处理器提供信息输入或者输出。和/或，所述通信接口702可以用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路(Wi-Fi、蓝牙、通用无线传输、车载短距通信技术以及其他短距无线通信技术等)接口。

存储器703用于提供存储空间，存储空间中可以存储操作系统和计算机程序等数据。存储器703可以是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read onlymemory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)等等中的一种或者多种的组合。

该计算机设备70中的至少一个处理器701用于调用至少一个存储器703中存储的计算机程序，用于执行前述的数据查询方法，例如前述图3、图4所示实施例所描述的数据查询方法。

在一种可能的实施方式中，该计算机设备70中的处理器701用于调用至少一个存储器703中存储的计算机程序，用于执行以下操作：调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到目标存储系统中的；若查询结果指示目标存储系统中存在数据对象，则根据目标存储系统中各个数据对象包括的延迟查询时间，从目标存储系统中确定第一数据对象；根据第一数据对象确定对应的第一业务交易的支付结果。

在一实施例中，处理器701还用于：当第二业务交易对应的支付请求提交成功时，生成支付请求对应的第二数据对象；调用数据存储线程将第二数据对象存储至目标存储系统中，并唤醒数据查询线程。

在一实施例中，处理器701具体用于：获取第二业务交易对应的支付请求提交成功时的参考时间戳，支付请求包括支付渠道标识和支付订单标识；根据参考时间戳和预设时长生成延迟查询时间；根据延迟查询时间、支付渠道标识和支付订单标识生成支付请求对应的第二数据对象。

在一实施例中，处理器701具体用于：比较目标存储系统中各个数据对象包括的延迟查询时间；将目标存储系统中包括的延迟查询时间最小的数据对象确定为第一数据对象。

在一实施例中，各个数据对象还包括支付订单标识和支付渠道标识，处理器701具体用于：若第一数据对象包括的延迟查询时间小于或等于当前时间，则根据第一数据对象包括的支付渠道标识确定目标支付渠道；调用目标支付渠道的查询接口，根据第一数据对象包括的支付订单标识获取对应的第一业务交易的支付结果。

在一实施例中，处理器701还用于：若支付结果指示的支付状态为支付成功或支付失败，则调用数据查询线程将支付结果更新至目标数据库中，并将第一数据对象从目标存储系统中删除。

在一实施例中，处理器701还用于：若支付结果指示的支付状态为待支付，则根据当前时间对目标存储系统中存储的第一数据对象包括的延迟查询时间进行更新处理；或者，根据第一数据对象生成第三数据对象，调用数据存储线程将第一数据对象从目标存储系统中删除，并将第三数据对象存储至目标存储系统中，第三数据对象包括的延迟查询时间是通过对第一数据对象包括的延迟查询时间进行更新处理得到的。

在一实施例中，处理器701还用于：若查询结果指示目标存储系统中不存在数据对象，则对数据查询线程进行阻塞处理。

应当理解，本申请实施例中所描述的计算机设备70可执行前文所对应实施例中对该数据查询方法的描述，也可执行前文图3或图4所对应实施例中对该数据查询装置60的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，还应指出，本申请一个示例性实施例还提供了一种存储介质，该存储介质中存储了前述数据查询方法的计算机程序，该计算机程序包括程序指令，当一个或多个处理器加载并执行该程序指令，可以实现实施例中对数据查询方法的描述，这里不再赘述，对采用相同方法的有益效果描述，也在此不再赘述。可以理解的是，程序指令可以被部署在一个或能够互相通信的多个计算机设备上执行。

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

本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例中一方面提供的方法。

本申请的一个方面，提供了另一种计算机程序产品，该计算机程序产品包括计算机程序或计算机指令，该计算机程序或计算机指令被处理器执行时实现本申请实施例提供的数据查询方法的步骤。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (10)

1.一种数据查询方法，其特征在于，所述方法包括：

调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个所述数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到所述目标存储系统中的；

若所述查询结果指示所述目标存储系统中存在数据对象，则根据所述目标存储系统中各个数据对象包括的延迟查询时间，从所述目标存储系统中确定第一数据对象；

根据所述第一数据对象确定对应的第一业务交易的支付结果。

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

当第二业务交易对应的支付请求提交成功时，生成所述支付请求对应的第二数据对象；

调用数据存储线程将所述第二数据对象存储至所述目标存储系统中，并唤醒所述数据查询线程。

3.如权利要求2中所述的方法，其特征在于，所述生成所述支付请求对应的第二数据对象，包括：

获取所述第二业务交易对应的支付请求提交成功时的参考时间戳，所述支付请求包括支付渠道标识和支付订单标识；

根据所述参考时间戳和预设时长生成延迟查询时间；

根据所述延迟查询时间、所述支付渠道标识和所述支付订单标识生成所述支付请求对应的第二数据对象。

4.如权利要求1所述的方法，其特征在于，所述根据所述目标存储系统中各个数据对象包括的延迟查询时间，从所述目标存储系统中确定第一数据对象，包括：

比较所述目标存储系统中各个数据对象包括的延迟查询时间；

将所述目标存储系统中包括的延迟查询时间最小的数据对象确定为第一数据对象。

5.如权利要求4所述的方法，其特征在于，所述各个数据对象还包括支付订单标识和支付渠道标识，所述根据所述第一数据对象确定对应的第一业务交易的支付结果，包括：

若所述第一数据对象包括的延迟查询时间小于或等于当前时间，则根据所述第一数据对象包括的支付渠道标识确定目标支付渠道；

调用所述目标支付渠道的查询接口，根据所述第一数据对象包括的支付订单标识获取对应的第一业务交易的支付结果。

6.如权利要求1～5中任一项所述的方法，其特征在于，所述方法还包括：

若所述支付结果指示的支付状态为支付成功或支付失败，则调用所述数据查询线程将所述支付结果更新至目标数据库中，并将所述第一数据对象从所述目标存储系统中删除。

7.如权利要求1～5中任一项所述的方法，其特征在于，所述方法还包括：

若所述支付结果指示的支付状态为待支付，则根据当前时间对所述目标存储系统中存储的第一数据对象包括的延迟查询时间进行更新处理；或者，

根据所述第一数据对象生成第三数据对象，调用所述数据存储线程将所述第一数据对象从所述目标存储系统中删除，并将所述第三数据对象存储至所述目标存储系统中，所述第三数据对象包括的延迟查询时间是通过对所述第一数据对象包括的延迟查询时间进行更新处理得到的。

8.如权利要求1～5中任一项所述的方法，其特征在于，所述方法还包括：

若所述查询结果指示所述目标存储系统中不存在数据对象，则对所述数据查询线程进行阻塞处理。

9.一种数据查询装置，其特征在于，包括：

调用模块，用于调用数据查询线程查询目标存储系统中是否存在数据对象，得到查询结果；每个所述数据对象是在对应的业务交易的支付请求提交成功之后，通过调用数据存储线程存储到所述目标存储系统中的；

确定模块，用于若所述查询结果指示所述目标存储系统中存在数据对象，则根据所述目标存储系统中各个数据对象包括的延迟查询时间，从所述目标存储系统中确定第一数据对象；

所述确定模块，还用于根据所述第一数据对象确定对应的第一业务交易的支付结果。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，执行权利要求1～8中任一项所述的数据查询方法。

Images