A data query method, apparatus, and computer-readable storage medium

Abstract

This application discloses a data query method, apparatus, and computer-readable storage medium. The data query method includes: invoking a data query thread to query whether a data object exists in a target storage system, and obtaining a query result; each data object is stored in the target storage system by invoking a data storage thread after the payment request for the corresponding business transaction is successfully submitted; if the query result indicates that a data object exists in the target storage system, then a first data object is determined from the target storage system based on the latency query time included in each data object; and the payment result of the corresponding first business transaction is determined based on the first data object. This application embodiment can reduce the logical complexity of querying payment results, thereby effectively improving the efficiency of obtaining payment results.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data query method, apparatus, and computer-readable storage medium. Background Technology

[0002] With the rapid development of the Internet era, various business activities have undergone tremendous evolution in terms of digitalization and informatization, giving rise to today's e-commerce. All kinds of e-commerce business activities cannot be separated from the management of various transaction behaviors generated in the business system by the payment system.

[0003] In practical internet applications, for transaction security reasons, regardless of the payment method, the business system needs to obtain the payment result after invoking a third-party payment channel (hereinafter referred to as the payment channel). Querying the payment result is essential. This process requires considering not only the payment channel's callback but also actively querying the payment channel to obtain the payment result. Traditional methods such as database polling or intervening in other intermediate components increase code complexity and waste database resources. Therefore, it is necessary to propose a simple and efficient method to obtain the payment result. Summary of the Invention

[0004] This application provides a data query method, apparatus, and computer-readable storage medium, which can reduce the logical complexity of querying payment results and thus effectively improve the efficiency of obtaining payment results.

[0005] This application provides a data query method, including:

[0006] The data query thread is invoked to check whether the data object exists in the target storage system and obtain the query results; each data object is stored in the target storage system by invoking the data storage thread after the payment request of the corresponding business transaction is successfully submitted.

[0007] If the query results indicate that a data object exists in the target storage system, then the first data object is determined from the target storage system based on the latency query time included in each data object in the target storage system.

[0008] The payment result of the corresponding first business transaction is determined based on the first data object.

[0009] One embodiment of this application provides a data query device, including:

[0010] The calling module is used to call the data query thread to query whether the data object exists in the target storage system and obtain the query results; each data object is stored in the target storage system by calling the data storage thread after the payment request of the corresponding business transaction is successfully submitted.

[0011] The determination module is used to determine the first data object from the target storage system based on the delayed query time included in each data object in the target storage system if the query result indicates that a data object exists in the target storage system.

[0012] The determination module is also used to determine the payment result of the corresponding first business transaction based on the first data object.

[0013] One embodiment of this application provides a computer device, including: a processor and a memory;

[0014] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the methods described in the embodiments of this application.

[0015] One aspect of this application provides a computer-readable storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions perform the methods described in this application.

[0016] Accordingly, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0017] In this embodiment, the data object corresponding to the business transaction is written into the target storage system by calling the data storage thread, and the data query thread is called to query and determine the data object in the target storage system. The payment result of the business transaction is then queried based on the data object. The whole process only requires calling two functional threads to query the payment result, which reduces the logical complexity of the payment result query and thus effectively improves the efficiency of obtaining the payment result. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is an architecture diagram of a data query system provided in an embodiment of this application;

[0020] Figure 2This is a schematic diagram illustrating a data query-related service call provided in an embodiment of this application;

[0021] Figure 3 This is a flowchart illustrating a data query method provided in an embodiment of this application;

[0022] Figure 4 This is a flowchart illustrating another data query method provided in an embodiment of this application;

[0023] Figure 5 This is a flowchart illustrating another data query method provided in an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of the structure of a data query device provided in an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] To better understand the solutions of the embodiments of this application, the relevant terms and concepts that may be involved in the embodiments of this application will be introduced below.

[0028] Redis: A high-performance key-value storage system that supports master-slave synchronization. Data can be synchronized from the master server to any number of slave servers. Runtime data is stored in memory, and it's a non-relational database that provides APIs (Application Programming Interfaces) in multiple languages. In modern internet projects, Redis is widely used in caching techniques, storing frequently accessed data from the database in Redis.

[0029] MySQL: A relational database management system, which is a type of relational database management system. Relational databases store data in different tables instead of putting all the data in one large repository. This can increase data retrieval speed and improve the flexibility of data storage.

[0030] Message Queue (MQ): A message queue is a mechanism that uses queues to deliver data messages.

[0031] RocketMQ is a reusable enterprise messaging system built on AMQP (Advanced Message Queuing Protocol). It is a distributed, queue-based open-source message middleware suitable for scenarios with high reliability requirements, especially order deduction in e-commerce and business peak shaving, where the backend may not be able to process a large influx of transactions in a timely manner.

[0032] Asynchronous processing: This means that after a request is sent, there is no need to wait for a response, and the next request can be triggered at any time.

[0033] Thread pool: A form of multithreaded processing where tasks can be added to a queue during processing, and then these tasks are automatically started after threads are created.

[0034] The architecture diagram of the data query system provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0035] Please see Figure 1 , Figure 1 This is an architecture diagram of an exemplary data query system provided in an embodiment of this application. Figure 1 As shown in the diagram, the architecture includes a data query device 101, a target storage device 102, a third-party payment device 103, and a target database 104.

[0036] The data query device 101 can deploy multiple functional systems, such as business systems and payment systems. Specifically, after the data query device 101 calls the payment interface of the third-party payment device 103, it stores a data object carrying a globally unique business number into the target storage device 102. The data query device 101 then queries the payment result according to the corresponding rules. Optionally, two thread pools can be started in the data query device 101 using a computer programming language (such as JAVA) to manage the data storage thread and the data query thread, respectively. The data storage thread is responsible for writing the data object corresponding to the business transaction that needs to obtain the payment result after submitting the payment request into the target storage device 102. The data query thread is responsible for querying the data object corresponding to the business transaction existing in the target storage device 102, and then obtaining the payment result from the third-party payment device 103 based on the obtained data object. That is, it calls the corresponding third-party payment channel, obtains the payment result, writes the obtained payment result into the target database 104, and deletes the corresponding data object from the target storage device 102.

[0037] It should be noted that when the data query thread does not find the data object for which the payment result needs to be queried in the target storage device 102, it can be blocked using the API provided by the corresponding thread, releasing resources. When the data object for which the payment result needs to be retrieved is stored in the target storage device 102, the data storage thread will write the data object to the target storage device 102 and wake up the data query thread to query the payment result. By controlling the presence or absence of the data object in the target storage device 102, the data query thread can be blocked or woken up, thereby preventing the data query thread from querying payment results when there are no unprocessed business transactions, reducing the access pressure on the database, and alleviating program idleness. In addition, the terms "payment channel" and "third-party payment channel" mentioned in this embodiment refer to the same meaning unless their distinction is emphasized, and can be used interchangeably.

[0038] The target storage device 102 can be used to store data related to business transactions for which payment results need to be retrieved. Specifically, this data exists in the form of data objects, which may include payment order identifiers, payment channel identifiers, and query latency. Optionally, the target storage device can be a Redis cluster, and the data object can be a pre-packaged Java object stored in a Redis ZSET data structure. By utilizing its anti-concurrency capabilities and the high efficiency of the Redis component, the querying of payment results for business transactions can be achieved.

[0039] Third-party payment device 103 is the backend device for third-party payment channels. A third-party payment channel refers to a platform that connects two parties to conduct online transactions through UnionPay or NetsUnion. Examples include UnionPay from major banks, various mobile payment methods (such as payment applications built into mobile phones), and applications developed by third-party companies that support payment services. The third-party payment device is equipped with a payment interface and a query interface. The payment interface is provided for devices that need to conduct business transactions; for example, a data query device can call the payment interface to implement order payment for a business transaction. The query interface is used by devices that need to obtain payment results; for example, data query device 101 can use data objects in the target storage device 102 to call the query interface of the third-party payment device to obtain the payment result of the corresponding business transaction. It should be noted that the third-party payment device 103 can include backend devices from multiple different payment platforms. The specific third-party payment device called when obtaining payment results can be determined based on the payment channel identifier in the data object.

[0040] The target database 104 can be used to store transaction order data, which may include payment order number, payment channel information, and payment result indicating whether the transaction order was successfully paid or failed. Optionally, when a third-party payment device queries the payment result of a transaction order and the conditions are met, the payment result and information of relevant data objects in the target storage device 102 can be updated to the target database 104 through a data query thread. Optionally, the target database 104 can be a relational database, such as MySQL.

[0041] It is understood that the data query device 101 can be installed in a terminal device or in a server, without restriction. The terminal device can be a smartphone, tablet, smart wearable device, personal computer, smart interactive device, smart in-vehicle device, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0042] It can be seen that the architecture of the above data query system does not require the introduction of message middleware, thus avoiding additional maintenance of the message middleware and reducing maintenance costs; the functional logic is simple and can achieve efficient payment result query.

[0043] Based on the architecture diagram of this data query system, more detailed information on the calls between various software-level systems can be found in [link to diagram]. Figure 2 The diagram illustrates a service call related to data querying, such as... Figure 2 As shown, it includes multiple business systems (including 201A, 201B, and 201C), a payment system 202, multiple third-party payment platforms (including 203A and 203B), a target storage system 204, and a database 205.

[0044] Business systems 201A, 201B, and 201C can be different functional business systems within the same application. Any one of these business systems and payment system 202 can form different functional modules within the same application. Taking an online shopping platform as an example, the business systems mainly implement functions such as platform user registration, product pricing, and marketing activities, while payment system 202 is the module that supports the business systems in conducting transactions, through communication with third-party payment channels (i.e.,...). Figure 2The third-party payment platform 203A and third-party payment platform 203B communicate to process transaction orders generated by business transactions. Typically, the business system records user purchase behavior in the form of various transaction orders and delivers them to the payment system 202 for processing, ultimately completing the collection and payment.

[0045] Third-party payment platforms 203A and 203B belong to different third-party payment channels. Through the integration of payment system 202 and the third-party payment platforms, business transactions can be conducted. From the user's perspective, a third-party payment channel refers to a specific payment method supported by the payment system. Optionally, the third-party payment channels provided to users may include at least one, allowing users to choose a suitable payment channel for business transactions. Optionally, after receiving and responding to the user's selection instruction, the payment system invokes the target payment channel based on the payment channel identifier carried in the selection instruction. After a successful invocation, the order data (i.e., data object) of the corresponding business transaction is stored in a fixed target storage system 204. This order data includes the business order number (i.e., payment order identifier), as well as the payment channel identifier and a delayed query time, all of which can be stored in the target storage system 204. The delayed query time is a preset time specified for querying payment results. The target storage system 204 may be a Redis cluster.

[0046] By using the order data stored in the target storage system 204, including the payment channel identifier and the payment order identifier, the specific payment channel can be retrieved, the payment result of the business transaction can be obtained, and then the relevant data in the target storage system 204 can be updated to the database 205, as well as the payment result indicating the payment status can be updated to the database 205.

[0047] During the aforementioned service call, the target storage system 204 can function as a message middleware, enabling data production and consumption. When data consumption cannot keep pace with production, the data objects requiring payment results are stored in the target storage system and await consumption. This prevents the original database from crashing due to sudden overload requests, avoids frequent polling queries, and reduces database access pressure. The entire process does not require deploying a message middleware, avoiding the consumption of more server resources and manpower for maintenance. Furthermore, when using a Redis cluster in the target storage system, Redis's inherent fault tolerance mechanisms, such as cluster deployment and data persistence, ensure that the data requiring payment results is not lost, preventing situations where payment results cannot be obtained. Moreover, Redis's high performance effectively guarantees the real-time nature of payment result retrieval.

[0048] Furthermore, for ease of understanding, please refer to Figure 3 , Figure 3 This is a flowchart illustrating a data query method provided in an embodiment of this application. This data query method can be performed by a computer device (as described above). Figure 1 The data query method, executed by the data query device in the system, includes, but is not limited to, the following steps:

[0049] S301, invoke the data query thread to query whether the data object exists in the target storage system and obtain the query result.

[0050] In this embodiment of the application, each data object is stored in the target storage system by calling the data storage thread after the payment request for the corresponding business transaction is successfully submitted.

[0051] Before invoking the data query thread, the data storage thread can be invoked to store the data object in the target storage system. Alternatively, the data storage thread can be invoked simultaneously with the data query thread to store the data object in the target storage system. For each business transaction, the data query device can initiate a payment request to a third-party payment channel based on the user's selected payment method or an automatically associated payment method. When the third-party payment channel is successfully invoked, the payment request is considered successfully submitted, and the data object can then be stored in the target storage system by invoking the data storage thread. In some cases, such as when the payment result for a business transaction is successful, but due to objective factors such as network lag or device issues, the payment result is not retrieved in time, causing the user to initiate a payment request again. In this case, the corresponding payment request will fail, the third-party payment channel will not be successfully invoked, and the data query device's payment system will be returned directly.

[0052] The target storage system is a tool used to store data objects, supporting the storage of massive amounts of data objects. Preferably, the target storage system can be a high-performance Redis database, or other storage systems that support high-concurrency data writing and querying; there are no restrictions here. Taking Redis as an example, since it not only supports simple key-value data types but also provides storage for data structures such as lists, sets, sorted sets (zsets), and hashes, the data objects in this embodiment can be specifically stored in the Redis zset data structure. A delayed queue can be constructed using zsets to implement the function of a message broker. Furthermore, due to Redis's high-performance characteristics, it can effectively improve the throughput of data queries and reduce the access pressure on the database. In addition, due to Redis's own fault tolerance mechanisms, such as cluster deployment, even if a storage device fails, the entire system will not be unable to actively obtain payment results, thereby improving the robustness of the entire system. The data storage thread and the data query thread can be threads managed by different thread pools and can be deployed in the payment system of the data query device using a computer programming language (such as Java).

[0053] It should be noted that using a thread pool for storing and retrieving data objects effectively improves system efficiency, reduces system load, and further enhances the efficiency of payment result retrieval. This is because a thread pool can flexibly control the number of threads according to system needs and hardware environment, and allows for unified management and control of all threads.

[0054] In this embodiment, the query result obtained by the data query thread is used to indicate whether a data object exists in the target storage system. The query result includes two types: ① If the query result indicates that a data object exists in the target storage system, corresponding processing can be performed according to steps S302-S303 below. ② If the query result indicates that no data object exists in the target storage system, the data query thread is blocked. Blocking the data query thread when there is no data object with a query result in the target storage system releases resources, thereby reducing unnecessary consumption of system resources. Subsequently, when the data storage thread stores the data object again in the target storage system, the data query thread can be automatically woken up to execute steps S302-S303. It should be noted that, to avoid unnecessary waste of resources, it is necessary to further indicate subsequent processing using the query result obtained from querying the target storage system.

[0055] S302, if the query result indicates that a data object exists in the target storage system, then the first data object is determined from the target storage system based on the delayed query time included in each data object in the target storage system.

[0056] In this embodiment, the data object includes a delayed query time. This delayed query time refers to the time when the data query thread is invoked to query the payment result of the business transaction corresponding to the data object; specifically, it is a point in time, such as 10:00:03. The delayed query time can be accurate to the second or the millisecond. When the target storage system contains only one data object, that data object is the first data object. When the target storage system contains two or more data objects, the data object processed first can be determined according to the order of its delayed query time.

[0057] Optionally, the first data object can be determined by comparing the query delay times of each data object in the target storage system; and selecting the data object with the smallest query delay time in the target storage system as the first data object. By comparing the query delay times of each data object, the data object with the smallest query delay time (i.e., the earliest query delay time) is selected as the first data object, and then processed subsequently. Similar to the first-in-first-out (FIFO) rule of a queue, the data objects stored in the target storage system are considered as a queue, with the order of query delay times used as the criteria for entry and exit. This ensures that the data objects that need processing first are processed promptly, thereby improving the efficiency of obtaining payment results. It should be noted that if multiple data objects have the same query delay time, one data object can be randomly selected as the first data object for subsequent processing. Alternatively, multiple data objects that meet the query delay time condition can be used as the first data object, and multiple data query threads can be activated simultaneously to determine the payment result for the corresponding first business transaction based on the first data object.

[0058] S303, determine the payment result of the corresponding first business transaction based on the first data object.

[0059] In one embodiment, since each data object corresponds one-to-one with a business transaction, which can specifically be a transaction order or a payment order, the business transactions corresponding to different data objects are different; therefore, the data objects are unique. This uniqueness can be specifically reflected in the payment order identifier included in the data object. The relevant data of the business transaction, including the query delay time, payment channel identifier, and payment order identifier, are all encapsulated in the data object. In addition to the query delay time, the first data object may also include a payment channel identifier and a payment order identifier. The payment order identifier is represented numerically, specifically as a payment order number. The payment channel identifier can be used to indicate payment channel information. This payment channel identifier is unique for different third-party payment channels, but may be the same for different data objects. For example, the payment channel identifiers in data object A and data object B both indicate payment channel C. The first business transaction is the business transaction for which the payment result is to be queried, specifically, it can be the transaction order corresponding to the first data object.

[0060] Optionally, the payment result of the first business transaction can be determined as follows: if the delayed query time included in the first data object is less than or equal to the current time, then the target payment channel is determined according to the payment channel identifier included in the first data object; the query interface of the target payment channel is called, and the payment result of the corresponding first business transaction is obtained according to the payment order identifier included in the first data object.

[0061] In other words, before calling the third-party payment channel's query interface to obtain the payment result, the delayed query time included in the first data object needs to be compared with the current time to determine whether the current time has reached the preset payment result query time. Here, the current time and the delayed query time can be time points. For example, if the current time is 10:00:03 and the delayed query time is 10:00:05, the current time has not reached the delayed query time, and the data query thread will not call the third-party payment channel's query interface to query the payment result. Conversely, when the current time reaches the delayed query time (i.e., the current time is greater than or equal to the delayed query time), the data query thread can query the payment result of the first business transaction based on the information stored in the first data object, including the payment channel identifier and the payment order identifier. Specifically, it can first determine the corresponding target payment channel based on the payment channel identifier. After determining the target payment channel, it can call the query interface provided by the target payment channel with the payment order identifier to query the payment result of the corresponding first business transaction on the third-party payment channel, thereby obtaining whether the user has paid for the first business transaction.

[0062] The method described above for determining the first data object, by delaying the query time to decide whether the data query thread should call the query interface of the third-party payment channel, avoids the data query thread from calling the third-party payment channel's query interface when there is no payment result. This reduces the probability of the data query thread running idle, thus efficiently utilizing system resources for querying payment results. It should be noted that the above method for determining the payment result of the first business transaction can also be applied to querying the payment results of business transactions corresponding to the remaining data objects in the target storage system. That is, a data object is determined based on the delayed query time during each processing, and the payment result of the business transaction corresponding to that data object is queried using the same method. This allows determining the payment results of all data objects stored in the target storage system corresponding to business transactions. This payment result indicates the payment status of the business transaction. The payment status can include payment success, payment failure, and pending payment. Based on different payment results, the data objects can be updated or deleted accordingly. See [link to relevant documentation] for details. Figure 4 The details of the corresponding embodiments will not be described in detail here.

[0063] It should be noted that the data query thread and data storage thread in this embodiment can be implemented through appropriate programming, such as Java programs. Such programming facilitates developers' control over the entire system (such as the aforementioned business system, payment system, and target storage system) and the rational allocation of project resources. Especially when no payment transactions occur, the data query thread will be blocked, thus preventing waste of server and database resources.

[0064] In summary, this embodiment has at least the following advantages:

[0065] By invoking a data query thread to check if data objects exist in the target storage system, resources can be released when no data objects are found, avoiding unnecessary resource consumption. If data objects exist, the data query thread will then query the payment results of the corresponding business transactions. The processing order of data objects in the target storage system can be determined based on the query delay time, which can also determine whether the data query thread calls the payment channel to obtain the payment result. By setting these two conditions—the existence of data objects and whether the current time has reached the delay time—device and computing resources can be maximized to enable the data query thread, thereby efficiently determining the payment results of the corresponding business transactions.

[0066] Furthermore, for ease of understanding, please refer to Figure 4 , Figure 4This is a flowchart illustrating another data query method provided in an embodiment of this application. This data query method can be performed by a computer device (as described above). Figure 1 The data query method, executed by the data query device in the system, includes, but is not limited to, the following steps:

[0067] S401, when the payment request corresponding to the second business transaction is successfully submitted, the second data object corresponding to the payment request is generated.

[0068] In one embodiment, the second business transaction is the transaction currently submitting a payment request to a third-party payment channel. Optionally, the determination of successful submission of the payment request corresponding to the second business transaction can be made as follows: based on the payment channel identifier included in the received payment request corresponding to the second business transaction, determine the target payment channel from one or more provided payment channels; call the payment interface of the target payment channel; when a notification message indicating a successful call is received from the target payment channel, it is determined that the payment request has been successfully submitted. Since the payment system can provide users with at least one payment channel to choose from, or the payment system can automatically associate a fixed payment channel for business transactions, regardless of the method, ultimately a specific payment channel, i.e., the payment interface of the target payment channel, will be called to complete the payment of the corresponding business transaction. When the payment system receives a notification message indicating that the target payment channel has been successfully called, it indicates that the payment request has been successfully submitted. Taking a user purchasing goods using an online shopping platform as an example, when the user clicks "checkout," a transaction order is generated. After selecting a payment channel and clicking "submit order," the user is redirected to the interface of the third-party payment channel prompting the user to enter a payment password. This step indicates that the payment system has successfully submitted a payment request to the third-party payment channel, and this transaction order is the second business transaction. After a payment request is successfully submitted, a corresponding second data object can be generated in the payment system.

[0069] Furthermore, generating the second data object corresponding to the payment request can involve: obtaining the reference timestamp of the successful submission of the payment request for the second business transaction, where the payment request includes a payment channel identifier and a payment order identifier; generating a delayed query time based on the reference timestamp and a preset duration; and generating the second data object corresponding to the payment request based on the delayed query time, the payment channel identifier, and the payment order identifier. The reference timestamp of the successful submission of the payment request for the second business transaction can be used as the starting time point. Adding the preset duration to this starting time point yields the delayed query time. The preset duration is the time information for the delayed query, and its range can be 3 to 5 seconds. This preset duration is the operation time given to the user for the payment action, i.e., it is expected that the user will complete the payment operation within the preset duration, such as entering a password on the interface for entering a payment password in the aforementioned example. For example, if the reference timestamp of the successful submission of the payment request is 10:00:00 and the preset duration is 5 seconds, then the delayed query time generated based on the reference timestamp and the preset duration is 10:00:05. Meanwhile, the payment channel identifier included in the payment request can be generated automatically by the system from a third-party payment channel, or it can be generated based on the user selecting a target payment channel from multiple payment channels; the payment order identifier included in the payment request can be a payment order number, which can be automatically generated by the payment system. After successfully submitting the payment request to the third-party payment channel, the payment system can encapsulate the above payment order identifier, payment channel identifier, and delayed query time into a second data object.

[0070] S402, call the data storage thread to store the second data object in the target storage system and wake up the data query thread.

[0071] In one embodiment, the data storage thread can store the encapsulated second data object into the target storage system. For data information generated when payment requests for different business transactions are successfully submitted, including delayed query time, payment order identifier, and payment channel identifier, data objects corresponding to the business transactions can be generated in the same way as the second data object generated in step S401, and then stored in the target storage system. The timing for waking the data query thread can be either when the first data object is stored in the target storage system, or before waking: determine if the data query thread is in a blocked state; if so, wake the data query thread; otherwise, maintain the existing state of the data query thread. This is because the data object stored by the data storage thread and the data object processed by the data query thread are not necessarily synchronized, and the data query thread may not be used for the first time. For example, when the data query thread has processed all data objects in the target storage system and the payment results are all successful, according to the corresponding processing of the payment results, there are no data objects in the target storage system at this time, and no new data objects are stored. As described in the aforementioned embodiment, the data query thread will be blocked. After a period of time, new data objects enter the target storage system. At this point, the data query thread needs to be awakened to retrieve the corresponding data objects for processing. It should be noted that if the data storage thread is continuously storing data objects, it can awaken a matching number of data query threads based on the number of data objects for subsequent processing. This matching number can be a proportional number of data objects to data query threads, or a one-to-one correspondence.

[0072] It should be noted that the execution order of steps S401 to S402 before steps S403 is only an example and is not necessarily required. The data storage thread can be called to store the data object before, after, or at the same time as the data query thread queries the data object.

[0073] S403 calls the data query thread to check if the data object exists in the target storage system and obtains the query result.

[0074] S404, if the query result indicates that a data object exists in the target storage system, then determine the first data object from the target storage system based on the delayed query time included in each data object in the target storage system.

[0075] S405, determine the payment result of the corresponding first business transaction based on the first data object.

[0076] Steps S403 to S405 described above can be found in S301 to S303 of the aforementioned embodiments, and will not be repeated here. The following content mainly describes the processing of different payment results.

[0077] In one embodiment, if the payment result indicates a payment success or payment failure, the data query thread is invoked to update the payment result in the target database and delete the first data object from the target storage system. That is, if the first business transaction has been paid or deducted but a payment failure result is displayed, the data query thread can delete the corresponding first data object from the target storage system after obtaining the payment result. This avoids subsequent repeated queries for the corresponding payment result based on that data object. Simultaneously, the payment result can be updated in the target database, which can be a relational database, such as a MySQL database. Regardless of whether the payment is successful or failed, the payment result recorded in the target database indicates that the business transaction has been completed.

[0078] In another embodiment, if the payment result indicates a pending payment status, the delayed query time included in the first data object stored in the target storage system is updated according to the current time; alternatively, a third data object is generated based on the first data object, the data storage thread is invoked to delete the first data object from the target storage system, and the third data object is stored in the target storage system. The delayed query time included in the third data object is obtained by updating the delayed query time included in the first data object. In other words, if the first business transaction is a pending payment result, it indicates that the first business transaction has not yet been paid, and a preset payment result query time needs to be set again. That is, the original delayed query time of the first data object is updated, changing the original delayed query time to prevent the data query thread from continuously querying the corresponding payment result based on the data object, resulting in invalid queries. Here, the update of the delayed query time can be generated by adding a preset duration to the time point when the payment result is obtained. Optionally, it can also be obtained by adding a preset duration by a preset multiple to the original delayed query time; no limitation is imposed here. The above payment result, when pending payment, includes two processing methods: one is to directly replace the delayed query time in the first data object with the updated delayed query time; the other is to generate a third data object based on the first data object, the only difference between the third and first data objects being the delayed query time. Subsequently, the data storage thread can be called to store the third data object in the target storage system, and the first data object can be deleted. Both methods can achieve the updating of the delayed query time, and the data objects are in the target storage system, waiting for the next query of the payment result of the corresponding business transaction.

[0079] The delayed query time is determined when a data object is used for the first query of its corresponding payment result, based on the reference time of successful payment request submission and a preset duration. However, when the data object is not used for the first query of its corresponding payment result, the delayed query time is determined based on the time point when the payment result is obtained and the preset duration. That is, when the payment result is pending payment, it is necessary to poll the payment result corresponding to the data object, and the corresponding delayed query time will change accordingly. For example, suppose user A specifies a target payment channel for a certain order, and the successful call to that target payment channel occurs at 10:00 AM, with a preset duration of 5 seconds. The first query time for the payment result is 10:00:05. However, if the corresponding payment result is found to be pending payment at 10:00:06, the delayed query time needs to be adjusted, for example, to 10:00:11. This means that after 10:00:11, the data query thread needs to call the third-party channel's query interface to obtain the payment result. By setting a delayed query time, not only can the data query thread be avoided from being called when there is no payment result, but the timing of the data query thread being called can also be effectively avoided when the payment result is pending payment, thereby effectively utilizing system resources to query payment results.

[0080] It should be noted that the aforementioned data query thread can also be called the payment result query thread. For payment results that are pending payment, in addition to adjusting the delay query time, the waiting time of the data query thread can also be set directly. For example, the data query thread can wait for a preset time (e.g., 15 seconds) before obtaining the data object and performing the payment result query processing.

[0081] Furthermore, it should be understood that, although Figure 4 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 4 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0082] In summary, this embodiment has at least the following advantages:

[0083] When a payment request corresponding to a business transaction is successfully submitted, the payment order identifier, payment channel identifier, and delay query time are encapsulated into a second data object and stored in the target storage system. This allows for an orderly and efficient determination of the payment result based on the data object, sequentially using the delay query time, payment channel identifier, and payment order identifier. Furthermore, for different payment results, the data objects in the target storage system are adjusted or deleted accordingly, avoiding duplicate queries and further improving the efficiency of payment result retrieval.

[0084] Based on the content described in the above embodiments, the following can be provided: Figure 5 This diagram illustrates another data query process. The target storage system is Redis, which is used as an example for illustration.

[0085] 1) After the payment system successfully submits a payment request to a third-party payment channel, it encapsulates the payment order number, payment channel information, and delayed query time into a data object (e.g., a Java object). This data object is then stored in a Redis ZSET data structure by calling the data storage thread. Simultaneously, the payment result query thread can be woken up (i.e.,...). Figure 5 The Java program in the polling thread queries the payment results.

[0086] 2) After the payment result query thread is awakened, it queries the data object in Redis. If data exists in Redis, it calls the payment channel to query the payment result. Specifically, it first obtains the delayed query time from the data object, determines the data object to be queried based on the delayed query time, and obtains the current time. By comparing the current time and the delayed query time, it decides whether to use the payment result query thread to call the third-party payment channel to query the payment result. Only if the current time is greater than the delayed query time will the payment result query thread, based on the information stored in the obtained data object (i.e., the specific third-party payment channel and payment order number), call the query interface provided by the third-party payment channel to query the payment result of the transaction order. Ultimately, it can obtain the result of whether the user has paid for the transaction order, i.e., the payment result.

[0087] 3) When the payment result obtained from the third-party channel is "payment successful", the payment result query thread can update the payment result of the transaction order to the transaction order data stored in the payment system's database, and then delete the data object corresponding to the transaction order in Redis. That is, the corresponding business order number, payment channel information, delayed query time information, etc. can all be cleared, which can avoid duplicate queries.

[0088] 4) When the payment result obtained from a third-party channel is "pending payment," the delayed query time in the data object corresponding to the transaction order stored in Redis can be updated, or the original data object corresponding to the transaction order can be deleted, and then the data object corresponding to the transaction order carrying the updated delayed query time can be rewritten into the Redis ZSET data structure. This process can be executed by the payment query thread, the data storage thread, or other threads; there are no restrictions on this.

[0089] It is understood that in this embodiment, the payment order number, payment channel information, and delayed query time correspond to the payment order identifier, payment channel identifier, and delayed query time in the aforementioned embodiments, respectively; the payment result query thread is the data query thread; and the transaction order corresponds to the business transaction.

[0090] In the above data query solution, the message queue functionality is implemented using Redis, which solves the asynchronous query scenario for obtaining payment results in the payment system without introducing new middleware technology, thus reducing project maintenance costs. Overall, it offers the following advantages: First, the functional logic is simple, requiring only Redis and eliminating the need for a message queue to handle verification results; second, using Redis to cache the database reduces database access pressure, prevents frequent polling queries, and effectively improves query performance. Furthermore, Redis's inherent fault tolerance mechanisms, such as cluster deployment and data persistence, ensure that the data requiring payment results is not lost, preventing situations where payment results cannot be obtained; third, the use of various threads can be adjusted through program design, enabling flexible control of system and project resources and effective and rational utilization of server and database resources.

[0091] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the structure of a data query device provided in an exemplary embodiment of this application. The aforementioned data query device can be a computer program (including program code) running on a computer device; for example, the data query device is an application software. The data query device can be used to execute corresponding steps in the methods provided in the embodiments of this application. Figure 6 As shown, the data query device 60 may include: a calling module 601 and a determining module 602, wherein:

[0092] Module 601 is invoked to call the data query thread to query whether the data object exists in the target storage system and obtain the query results; each data object is stored in the target storage system by calling the data storage thread after the payment request of the corresponding business transaction is successfully submitted.

[0093] The determining module 602 is used to determine the first data object from the target storage system based on the delayed query time included in each data object in the target storage system if the query result indicates that a data object exists in the target storage system.

[0094] The determining module 602 is also used to determine the payment result of the corresponding first business transaction based on the first data object.

[0095] In one embodiment, the data query device 60 further includes: a generation module 603, wherein:

[0096] The generation module 603 is used to generate a second data object corresponding to the payment request when the payment request corresponding to the second business transaction is successfully submitted.

[0097] Module 601 is also used to call the data storage thread to store the second data object into the target storage system and to wake up the data query thread.

[0098] In one embodiment, the generation module 603 is specifically used to: obtain a reference timestamp when the payment request corresponding to the second business transaction is successfully submitted, the payment request including a payment channel identifier and a payment order identifier; generate a delayed query time based on the reference timestamp and a preset duration; and generate a second data object corresponding to the payment request based on the delayed query time, the payment channel identifier, and the payment order identifier.

[0099] In one embodiment, the determining module 602 is specifically used to: compare the latency query times of each data object in the target storage system; and determine the data object with the smallest latency query time in the target storage system as the first data object.

[0100] In one embodiment, each data object further includes a payment order identifier and a payment channel identifier. The determination module 602 is further configured to: if the delayed query time included in the first data object is less than or equal to the current time, determine the target payment channel based on the payment channel identifier included in the first data object; call the query interface of the target payment channel, and obtain the payment result of the corresponding first business transaction based on the payment order identifier included in the first data object.

[0101] In one embodiment, the data query device 60 further includes an update module 604, configured to: if the payment status indicated by the payment result is payment success or payment failure, call the data query thread to update the payment result to the target database and delete the first data object from the target storage system.

[0102] In one embodiment, the update module 604 is further configured to: if the payment status indicated by the payment result is pending payment, update the delayed query time included in the first data object stored in the target storage system according to the current time; or, generate a third data object based on the first data object, call the data storage thread to delete the first data object from the target storage system, and store the third data object in the target storage system, wherein the delayed query time included in the third data object is obtained by updating the delayed query time included in the first data object.

[0103] In one embodiment, the data query device 60 further includes a blocking module 605, which is used to block the data query thread if the query result indicates that there is no data object in the target storage system.

[0104] It is understood that the functions of each functional module of the data query device 60 described in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0105] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 70 may include one or more independent devices (such as servers, nodes, terminals, etc.), or it may include components within independent devices (such as chips, software modules, or hardware modules). The computer device 70 may include at least one processor 701 and a communication interface 702. Optionally, the computer device 70 may also include at least one memory 703 and a bus 704. The processor 701, communication interface 702, and memory 703 are connected via the bus 704.

[0106] The processor 701 is a module that performs arithmetic and / or logical operations. Specifically, it can be one or a combination of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), a coprocessor (to assist the central processing unit in completing corresponding processing and applications), and a microcontroller unit (MCU).

[0107] The communication interface 702 can be used to provide information input or output to the at least one processor. And / or, the communication interface 702 can be used to receive data sent from outside and / or send data to outside, and can be a wired link interface including such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, vehicle short-range communication technology and other short-range wireless communication technologies, etc.).

[0108] The memory 703 provides storage space, in which data such as the operating system and computer programs can be stored. The memory 703 can be one or a combination of several of the following: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0109] At least one processor 701 in the computer device 70 is used to invoke a computer program stored in at least one memory 703 to execute the aforementioned data query method, such as the one described above. Figure 3 , Figure 4 The data query method described in the illustrated embodiment.

[0110] In one possible implementation, the processor 701 in the computer device 70 is used to invoke a computer program stored in at least one memory 703 to perform the following operations: invoke a data query thread to query whether a data object exists in the target storage system and obtain a query result; each data object is stored in the target storage system by invoking a data storage thread after the payment request for the corresponding business transaction is successfully submitted; if the query result indicates that a data object exists in the target storage system, then determine a first data object from the target storage system based on the delayed query time included in each data object in the target storage system; and determine the payment result of the corresponding first business transaction based on the first data object.

[0111] In one embodiment, the processor 701 is further configured to: generate a second data object corresponding to the payment request when the payment request corresponding to the second business transaction is successfully submitted; call the data storage thread to store the second data object in the target storage system, and wake up the data query thread.

[0112] In one embodiment, the processor 701 is specifically configured to: obtain a reference timestamp when the payment request corresponding to the second business transaction is successfully submitted, the payment request including a payment channel identifier and a payment order identifier; generate a delayed query time based on the reference timestamp and a preset duration; and generate a second data object corresponding to the payment request based on the delayed query time, the payment channel identifier, and the payment order identifier.

[0113] In one embodiment, the processor 701 is specifically configured to: compare the latency query times of each data object in the target storage system; and determine the data object with the smallest latency query time in the target storage system as the first data object.

[0114] In one embodiment, each data object further includes a payment order identifier and a payment channel identifier. The processor 701 is specifically configured to: if the delayed query time included in the first data object is less than or equal to the current time, determine the target payment channel based on the payment channel identifier included in the first data object; call the query interface of the target payment channel, and obtain the payment result of the corresponding first business transaction based on the payment order identifier included in the first data object.

[0115] In one embodiment, the processor 701 is further configured to: if the payment status indicated by the payment result is payment success or payment failure, call the data query thread to update the payment result to the target database and delete the first data object from the target storage system.

[0116] In one embodiment, the processor 701 is further configured to: if the payment status indicated by the payment result is pending payment, update the delayed query time included in the first data object stored in the target storage system according to the current time; or, generate a third data object based on the first data object, call the data storage thread to delete the first data object from the target storage system, and store the third data object in the target storage system, wherein the delayed query time included in the third data object is obtained by updating the delayed query time included in the first data object.

[0117] In one embodiment, the processor 701 is further configured to: block the data query thread if the query result indicates that no data object exists in the target storage system.

[0118] It should be understood that the computer device 70 described in the embodiments of this application can execute the data query method described in the corresponding embodiments above, and can also execute the methods described above. Figure 3 or Figure 4 The description of the data query device 60 in the corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0119] Furthermore, it should be noted that an exemplary embodiment of this application also provides a storage medium storing a computer program for the aforementioned data query method. This computer program includes program instructions that, when loaded and executed by one or more processors, can implement the data query method described in the embodiments, which will not be repeated here. The beneficial effects of employing the same method will also not be repeated here. It is understood that the program instructions can be deployed on one or more computer devices capable of communicating with each other for execution.

[0120] The aforementioned computer-readable storage medium can be the data query device provided in any of the foregoing embodiments or the internal storage unit of the aforementioned computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium may include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0121] One aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0122] In one aspect of this application, another computer program product is provided, which includes a computer program or computer instructions that, when executed by a processor, implement the steps of the data query method provided in the embodiments of this application.

[0123] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data query method, characterized in that, The method includes: The system invokes a data query thread to check if a data object exists in the target storage system and obtains the query results. Each data object is stored in the target storage system by invoking a data storage thread after the payment request for the corresponding business transaction is successfully submitted. Each data object encapsulates relevant data for the corresponding business transaction, including a delayed query time, a payment channel identifier, and a payment order identifier. The delayed query time for each data object is determined based on the reference timestamp of the successful submission of the payment request for the corresponding business transaction and a preset duration. If the query result indicates that a data object exists in the target storage system, then the query latency of each data object in the target storage system is compared, and the data object with the smallest query latency in the target storage system is determined as the first data object. If the delayed query time included in the first data object is less than or equal to the current time, then the target payment channel is determined according to the payment channel identifier included in the first data object, and the query interface of the target payment channel is called to obtain the payment result of the corresponding first business transaction according to the payment order identifier included in the first data object. The payment result is used to indicate the payment status of the first business transaction, and the payment status includes any one of payment success, payment failure, and pending payment.

2. The method as described in claim 1, characterized in that, The method further includes: When the payment request corresponding to the second business transaction is successfully submitted, a second data object corresponding to the payment request is generated; The data storage thread is invoked to store the second data object in the target storage system, and the data query thread is awakened.

3. The method as described in claim 2, characterized in that, The generation of the second data object corresponding to the payment request includes: Obtain the reference timestamp of the successful submission of the payment request corresponding to the second business transaction, wherein the payment request includes a payment channel identifier and a payment order identifier; A delayed query time is generated based on the reference timestamp and the preset duration; A second data object corresponding to the payment request is generated based on the delayed query time, the payment channel identifier, and the payment order identifier.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If the payment result indicates a payment success or payment failure, the data query thread is invoked to update the payment result in the target database, and the first data object is deleted from the target storage system.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If the payment result indicates a pending payment status, then the delayed query time included in the first data object stored in the target storage system is updated according to the current time; or, A third data object is generated based on the first data object. The data storage thread is invoked to delete the first data object from the target storage system and store the third data object in the target storage system. The delayed query time included in the third data object is obtained by updating the delayed query time included in the first data object.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If the query result indicates that no data object exists in the target storage system, the data query thread will be blocked.

7. A data query device, characterized in that, include: The calling module is used to invoke the data query thread to query whether a data object exists in the target storage system and obtain the query result. Each data object is stored in the target storage system by invoking the data storage thread after the payment request of the corresponding business transaction is successfully submitted. Each data object encapsulates relevant data of the corresponding business transaction, including delayed query time, payment channel identifier, and payment order identifier. The delayed query time included in each data object is determined based on the reference timestamp of the successful submission of the payment request of the corresponding business transaction and a preset duration. The determination module is used to compare the latency query time of each data object in the target storage system if the query result indicates that a data object exists in the target storage system, and determine the data object with the smallest latency query time in the target storage system as the first data object; The determining module is further configured to, if the delayed query time included in the first data object is less than or equal to the current time, determine the target payment channel based on the payment channel identifier included in the first data object, and call the query interface of the target payment channel to obtain the payment result of the corresponding first business transaction based on the payment order identifier included in the first data object. The payment result is used to indicate the payment status of the first business transaction, and the payment status includes any one of payment success, payment failure, and pending payment.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, perform the data query method according to any one of claims 1 to 6.

Images