Method of operating request execution and transaction operation system, computing device

Abstract

The embodiment of the specification provides an operation request execution method and a transaction operation system and a computing device, wherein the operation request execution method is applied to a transaction intermediary platform in the transaction operation system, and the method comprises the following steps: acquiring a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; triggering the transaction operation request in the transaction queue to be sequentially taken out and executed; in the case that the number of executed transaction operation requests reaches a first preset number and a preset time condition is met, triggering the non-transaction operation request in the non-transaction queue to be sequentially taken out and executed, wherein the execution priority of the non-transaction operation request is lower than that of the transaction operation request; in the case that the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, triggering the transaction operation request in the transaction queue to be sequentially taken out and executed. The collaborative optimization execution between the transaction operation request and the non-transaction operation request is realized.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification relate to the technical field of financial transaction, and in particular, relate to an operation request execution method, a transaction operation system, and a computing device. BACKGROUND

[0002] With the development of science and technology, the financial transaction system puts forward higher requirements on message processing efficiency and real-time performance.

[0003] At present, the transaction system usually processes all operation requests in a single thread or fixed queue mode, and completes various tasks such as order placement, return processing, query request, etc. by sequentially executing in the order of operation request reception. Some methods try to introduce a multi-queue scheduling mechanism, and allocate processing resources through a static division strategy.

[0004] However, in the above technical solution, since only the preset priority division rule is used to control the task switching of the transaction, there is a lack of dynamic scheduling logic for requests of various priorities, and it is difficult to dynamically execute operation requests with high priority, thereby causing high-priority operation requests to be blocked and delayed by low-priority operation requests, and further causing the timeliness of key transaction business execution to be affected, and affecting the execution efficiency and stability of the operation request of the financial transaction system. Therefore, there is an urgent need for a more reasonable and efficient operation request execution method. SUMMARY

[0005] Therefore, one or more embodiments of the present specification simultaneously relate to a transaction operation system, a computing device, a computer readable storage medium, and a computer program product to solve the technical defects in the prior art.

[0006] One aspect of an embodiment of the present specification provides an operation request execution method applied to a transaction intermediary platform in a transaction operation system, and the method comprises: acquiring a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; triggering a transaction operation request to be sequentially taken out from the transaction queue and executed; in the case that the number of executed transaction operation requests reaches a first preset number and a preset time condition is met, triggering a non-transaction operation request to be sequentially taken out from the non-transaction queue and executed, wherein the execution priority of the non-transaction operation request is lower than that of the transaction operation request; in the case that the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, jumping to sequentially take out a transaction operation request from the transaction queue and execute it.

[0007] By storing transaction operation requests with different execution priorities and non-transaction operation requests in mutually isolated transaction queues and non-transaction queues respectively, combining a dynamic switching mechanism of double verification of a preset quantity threshold and a preset time condition, in the case that the transaction queue is not empty, high-priority transaction operation requests are preferentially processed, in the case that the number of transaction operation request executions reaches a first preset number and the preset time condition is met, the system actively switches to the non-transaction queue to process low-priority non-transaction operation requests, and immediately reverts to the transaction queue when the number of non-transaction operation request executions reaches a second preset number, forming a dynamic scheduling mode of cyclic repetition, ensuring the priority execution of transaction operation requests and the execution guarantee of non-transaction operation requests, achieving dynamic balance between resource allocation and task scheduling, taking into account the overall efficiency of the transaction system and the timeliness requirements of key businesses, maintaining the overall response capability of the transaction operation system, reducing the context switching overhead, and realizing the cooperative optimization execution of transaction operation requests and non-transaction operation requests under a single-thread architecture. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1 is a schematic diagram of an operation request execution framework in the prior art;

[0009] Figure 2 is a flowchart of an operation request execution method provided by one embodiment of the present specification;

[0010] Figure 3 is a schematic diagram of a transaction operation system framework provided by one embodiment of the present specification;

[0011] Figure 4 is a processing framework schematic diagram of an operation request execution method provided by one embodiment of the present specification;

[0012] Figure 5 is a processing process flowchart of an operation request execution method provided by one embodiment of the present specification;

[0013] Figure 6 is a structural schematic diagram of a transaction operation system provided by one embodiment of the present specification;

[0014] Figure 7 is a structural block diagram of a computing device provided by one embodiment of the present specification. DETAILED DESCRIPTION

[0015] In the following description, many specific details are set forth in order to provide a thorough understanding of the present specification. However, the present specification can be practiced in many different ways beyond the specific embodiments described herein, and it is understood that persons having ordinary skill in the art can make similar modifications without departing from the spirit of the present specification, so the present specification is not limited to the specific implementations disclosed below.

[0016] The terminology used in this disclosure, one or more embodiments of the present specification, is for the purpose of describing particular embodiments only and is not intended to be limiting of one or more embodiments of the present specification. As used in this disclosure and the appended claims herein, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "and / or," as used in this disclosure, refers to and encompasses any or all possible combinations of one or more of the associated listed items.

[0017] It should be understood that although the terms first, second, etc. can be employed in this disclosure, one or more embodiments of the present specification, to describe various information, these information should not be limited to these terms. These terms are only used to differentiate one piece of information from another piece of information of the same type. For example, without departing from the scope of one or more embodiments of the present specification, first can also be referred to as second, and similarly, second can also be referred to as first. Depending on the context, the word "if" as used herein can be interpreted as meaning "when" or "in response to determining" or "in response to ascertaining".

[0018] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in one or more embodiments of the present specification are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0019] Firstly, the nomenclature involved in one or more embodiments of the present specification is explained.

[0020] First In, First Out (FIFO) is a queue processing mechanism that ensures tasks or data are processed in the order of receipt, with the first-in queue being the first-out queue, commonly used to ensure the order and timing consistency of transaction operation requests.

[0021] Transmission Control Protocol (TCP) interface is a communication interface based on TCP protocol, which can establish a connection through three-way handshake, provide reliable data transmission and sequential delivery, and is suitable for scenarios with high requirements for data integrity.

[0022] The User Datagram Protocol (UDP) interface is a communication interface based on the UDP protocol, which can send data packets without establishing a connection, has low latency characteristics, and is suitable for high-frequency trading scenarios with extremely high real-time requirements for transaction operation request transmission.

[0023] The seat is a unique legal identity assigned by the trading platform to the trading intermediary platform, used to verify the legality of transaction operation requests and ensure the execution authority and compliance of transaction instructions in the exchange system.

[0024] With the development of science and technology, financial transaction systems have higher requirements for message processing efficiency and real-time performance.

[0025] Currently, transaction systems typically use single-thread or fixed queue mode to process all operation requests, completing various tasks such as order placement, return processing, and query requests through sequential execution according to the order of operation request reception. Some methods attempt to introduce a multi-queue scheduling mechanism by allocating processing resources through static partitioning strategies.

[0026] Referring to Figure 1 , Figure 1 shows a schematic diagram of an operation request execution framework in the prior art, as shown in Figure 1 .

[0027] The user end first establishes a handshake connection with the main thread in the core thread of the transaction system and obtains a port, then disconnects the handshake connection; uses the port returned by the handshake connection to establish a TCP connection with the main thread and logs in; the main thread returns a login response, including a token field for identity verification; reuses the token field returned by login to place orders and cancel orders with the UDO order thread; performs capital and warehouse verification between the API thread of the order exchange in the transaction system and the order exchange API thread, and submits the order to the order exchange, where the API thread of the order exchange supports multiple seats; receives the order processing thread positioning returned by the exchange and inserts it into the return queue; updates the capital and position based on the return, and pushes the return.

[0028] In the main thread, the handshake connection function (binds port A), connection establishment and disconnection (epoll), port allocation according to account configuration permissions (different threads bind different ports), and management function processing.

[0029] In the User Datagram Protocol (UDP) order line, While (1) ---- bind port B1, B2

[0030] 1. Scan the naked protocol order and cancel order request (scan 10 times continuously each time)

[0031] 2. Scan the return queue to process return information

[0032] 3. Scan the TCP connection queue and process TCP requests (other function numbers except order placement and order cancellation)

[0033] 4. Process TCP connection and disconnection requests and maintain the TCP connection queue (one thread supports 16 connections).

[0034] In the TCP order placement thread, While (1) - bind ports C1 and C2

[0035] 1. Scan the TCP connection queue and process TCP requests (order placement, order cancellation, query and other requests)

[0036] 2. Scan the return queue and process return information

[0037] 3. Process TCP connection and disconnection requests and maintain the TCP connection queue (one thread supports 16 connections).

[0038] However, in the above technical solution, since only the preset priority division rule is relied on to control the task switching of transactions, there is a lack of dynamic scheduling logic for each priority request, it is difficult to dynamically execute operation requests with higher priority; login response, capital verification and warehouse verification, and other non-transaction operation requests are not distinguished from order placement transaction operation requests, thereby causing high-priority operation requests to be blocked and delayed by low-priority operation requests, and further causing the timeliness of key transaction business execution to be unable to be taken into account, affecting the execution efficiency and stability of operation requests of the financial transaction system.

[0039] Therefore, in the present specification, an operation request execution method is provided, and the present specification also relates to a transaction operation system, a computing device, a computer readable storage medium, and a computer program product, which are described in detail one by one in the following embodiments.

[0040] Referring to Figure 2 , Figure 2 A flowchart of an operation request execution method according to an embodiment of the present specification is shown, which is applied to a transaction intermediary platform in a transaction operation system, and specifically includes the following steps.

[0041] Step 202: Obtain a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue.

[0042] The operation request execution method provided in the embodiments of the present specification can be applied to a transaction operation system in the financial field. The transaction subject or transaction object in the transaction operation system can be stocks, bonds, futures, foreign exchange, etc., or physical goods or services, or digital rights, digital art, etc. digitalized rights. The embodiments of the present specification do not make specific limitations on this.

[0043] The transaction operation system is an integrated processing platform for coordinating the receiving, classification, execution and response of various operation requests in the transaction system under various transaction scenarios. Specifically, referring to Figure 3 , Figure 3 A framework diagram of a transaction operation system according to an embodiment of the present specification is shown, as Figure 3 indicated.

[0044] The transaction operation system can include a transaction mediation platform, and optionally, a user end and a transaction platform. The user end can be responsible for initiating transaction operation requests and / or non-transaction operation requests to the transaction mediation platform, and receiving transaction return responses and / or non-transaction result responses returned by the transaction mediation platform. The transaction mediation platform is used to receive and / or send transaction operation requests sent by the user end, determine transaction operation information sent to the transaction platform, receive transaction result returns returned by the transaction platform and / or automatically send update market information messages to the transaction mediation platform, and send transaction return responses and / or non-transaction result responses to the user end. The transaction platform is responsible for receiving transaction operation information sent by the transaction mediation platform, and returning transaction result returns, while automatically sending update market information messages to the transaction mediation platform at intervals of a preset time. For example, when the user end submits a transaction operation request of a placing order request, the transaction operation system receives the transaction operation request through the transaction mediation platform, determines the corresponding transaction operation information, sends it to the transaction platform, and receives the transaction result return of completing the actual transaction operation, generates a transaction return response and sends it to the user end.

[0045] The transaction mediation platform is the core scheduling module of the transaction operation system, which is used to obtain transaction queues and non-transaction queues, and sequentially take out and execute operation requests in the queues according to preset rules. Optionally, the transaction mediation platform can receive operation requests and put them into corresponding queues according to the request type. The transaction mediation platform processes high-priority transaction operation requests in the transaction queue through an independent thread, while periodically switching to process low-priority requests in the non-transaction queue, to ensure the timeliness of critical business.

[0046] The transaction queue is a special queue in the transaction mediation platform for storing high-priority transaction operation requests, used to ensure the real-time and stability of transaction operation requests (such as placing orders, canceling orders, etc.). The execution priority of the transaction queue is higher than that of the non-transaction queue. The transaction queue is processed exclusively by an independent thread, ensuring that transaction operation requests are executed in order in the transaction queue and are not disturbed by other low-priority tasks. For example, when a user submits a high-priority transaction operation request of “placing an order”, the transaction mediation platform will put the “placing an order” transaction operation request into the transaction queue and prioritize processing in the current scheduling period.

[0047] The non-trading queue is a special queue in the transaction mediation platform for storing low-priority non-trading operation requests, used to ensure the data integrity and system response capability of non-trading requests (such as query, login, and market update). The execution priority of the non-trading queue is lower than that of the trading queue, and the execution of the non-trading queue is triggered after the execution of the trading queue reaches a preset number threshold, and the periodic scheduling mechanism is used to ensure that the non-trading task gets an execution opportunity. For example, when the trading operation request is executed 100 times in a loop for the trading queue, the transaction mediation platform can switch to the non-trading queue and process the non-trading operation requests therein, such as user-submitted position information query requests.

[0048] Specifically, the transaction queue and the non-trading queue can be obtained directly from the local storage medium of the transaction operation system, or from the server cache of the transaction operation system, or from the cloud server through a cloud service provider. The embodiments of the present specification do not make specific limitations on this.

[0049] Optionally, for the transaction queue and the non-trading queue, the operation request sent by the user can be received and placed in the corresponding queue, so that the corresponding operation request can be sequentially taken out from the transaction queue or the non-trading queue in subsequent execution.

[0050] Optionally, for the classification of operation requests, the operation requests can be classified based on preset classification rules, such as keyword classification or operation object classification based on operation requests; or the operation requests can be directly classified based on the operation classification identifier carried in the operation request, such as function number.

[0051] Optionally, in the process of placing the operation request into the transaction queue or the non-trading queue, the source of the operation request also needs to be considered, and thread positioning is performed to realize separate execution based on different threads, thereby ensuring the independence between transaction businesses and the continuity within each thread.

[0052] In this step, by obtaining the transaction queue and the non-trading queue, a data basis is provided for subsequent execution of the transaction operation request and the non-trading operation request, and by obtaining the queue, physical isolation of operation requests with different priorities is realized.

[0053] Step 204: Triggering sequentially taking out the transaction operation request from the transaction queue and executing.

[0054] The transaction operation request is a high-priority operation instruction sent by a user terminal in a transaction operation system and needs to be dispatched and executed through a transaction intermediary platform. The execution priority of the transaction operation request is higher than that of a non-transaction operation request. The transaction operation request has strong requirements for execution real-time performance and stability. Specifically, the transaction operation request can usually include order placement, order cancellation and other operation requests, which usually need to be communicated with the transaction platform. The transaction operation request needs to be executed in sequence in the transaction queue to ensure the timeliness of key business.

[0055] For example, in a financial transaction scenario, when a user submits a stock buy order through a user terminal, the corresponding operation request is classified as a transaction operation request and dispatched to the transaction queue by the transaction intermediary platform for execution.

[0056] Specifically, the condition for triggering the sequential extraction of the transaction operation request from the transaction queue can include the initialization completion of the transaction queue or the state reset after the end of the previous dispatching period. Specifically, when the transaction intermediary platform completes the acquisition of the transaction queue and the non-transaction queue and confirms that there are transaction operation requests to be processed in the transaction queue, exclusive processing can be performed on the transaction queue, and the transaction operation request can be sequentially extracted and executed from the transaction queue.

[0057] Specifically, the transaction operation request in the transaction queue is sequentially extracted in accordance with the first-in first-out (FIFO) principle, ensuring that the transaction operation request can be executed in the order of receipt. The execution of the transaction operation request in the transaction queue is controlled by the transaction intermediary platform through an independent thread, and the transaction queue state is detected through continuous polling. When the queue is not empty, the request is extracted one by one to ensure the priority execution of the transaction operation request in the transaction queue.

[0058] Optionally, the continuous polling of the transaction queue can end when a preset number of polling is reached, or when a preset number of transaction operation requests are executed.

[0059] Specifically, the execution of the transaction operation request can be processed by the transaction intermediary platform, which can include verification processing, such as verifying the legality of the request, verifying the transaction eligibility, and updating the information of the transaction intermediary platform. After the transaction intermediary platform completes the processing of the transaction operation request, the transaction operation information can be obtained based on the transaction operation request. The transaction operation information is the operation information sent to the transaction platform, which can include the actual transaction task or transaction target. The transaction operation information can be sent through the connection relationship between the transaction intermediary platform and the transaction platform.

[0060] Specifically, the transaction platform usually has a preset API interface for communication connection and seat verification with the transaction intermediary platform. The transaction intermediary platform sends transaction operation information to the transaction platform through the interface of the transaction platform, and receives the returned transaction return response to complete the execution of the transaction operation request.

[0061] Exemplarily, in the financial transaction scenario, for the order request A taken out from the transaction queue, the transaction intermediary platform first verifies the user's funds and position to confirm the transaction qualification, and in the case of passing the verification, the transaction operation information corresponding to the order request A is reported to the transaction platform through the preset interface, and the execution result returned by the transaction platform is waited.

[0062] In this step, by sequentially taking out and executing the transaction operation request in the transaction queue, the transaction intermediary platform can realize exclusive execution of the transaction queue, guaranteeing exclusive processing of high-priority transaction operation requests and avoiding interference of low-priority non-transaction operation requests, thereby significantly reducing the delay of critical transaction business.

[0063] Step 206: In the case that the number of executed transaction operation requests reaches the first preset number and the preset time condition is met, sequentially taking out and executing non-transaction operation requests from the non-transaction queue, wherein the execution priority of the non-transaction operation request is lower than that of the transaction operation request.

[0064] The first preset number is a dynamic switching threshold set in the transaction operation system to control the execution frequency of the transaction operation request. The value of the first preset number can be determined by a system configuration file or a runtime parameter, which is used to measure the upper limit of processing of high-priority tasks in the transaction queue. Specifically, the setting of the first preset number needs to consider the throughput, delay tolerance and resource allocation strategy of the transaction system to ensure the real-time execution of high-priority transaction business while reserving an execution window for non-transaction operation requests. For example, when the first preset number is set to 100, the transaction intermediary platform will exit the exclusive processing thread after processing 100 transaction operation requests (such as order placement and order cancellation), and actively switch from the transaction queue to the non-transaction queue to execute low-priority non-transaction operation requests.

[0065] The preset time condition is a dynamic time judgment rule in the transaction operation system for switching from the transaction queue to the non-transaction queue. The preset time condition can be determined according to the time interval (i.e. time slice) of the transaction platform returning the updated market message to ensure that the waiting time for the updated market message is not too long to affect the basic response of the transaction operation system.

[0066] Optionally, the judgment of the preset time condition can be based on the association of the timestamp and the time window. Specifically, the judgment basis of the preset time condition can include: judging whether the current timestamp at which the first preset number of transaction operation requests are executed is within the dynamic time window defined by the updated market information message returned by the transaction platform. If yes, the transaction operation requests are sequentially taken out from the transaction queue and executed, and if not, the non-transaction operation requests are sequentially taken out from the non-transaction queue and executed. The judgment basis of the preset time condition can also include: judging whether the executed time of the transaction queue meets the preset time interval threshold calculated based on the current timestamp.

[0067] Exemplarily, in the financial transaction scenario, in the time slice in which the updated market information message is returned by the transaction platform, when the number of transaction operation requests reaches the first preset number, the current timestamp and the timestamp of the last updated market information message sent by the transaction platform can be further compared. If the current timestamp exceeds the dynamic time window determined by the timestamp of the updated market information message, the execution process of the non-transaction queue is triggered; otherwise, if the current timestamp is still within the time window, the transaction queue is continued to be processed preferentially.

[0068] The non-transaction operation request is a low-priority operation instruction initiated by the user end in the transaction operation system and needs to be dispatched and executed by the transaction intermediary platform. The execution priority of the non-transaction operation request is lower than that of the transaction operation request. The non-transaction operation request has higher requirements for data integrity and system response capability and lower requirements for real-time performance. Specifically, the non-transaction operation request can usually include query-type operations (such as account information query, position query, etc.), login verification, market information update, and other non-direct transaction state changing operation requests. Such operation requests usually do not need the participation of the transaction platform and can be directly executed through the transaction intermediary platform to complete the execution. The non-transaction operation request is sequentially executed in the non-transaction queue to ensure the overall response capability of the system.

[0069] Specifically, the taking out and execution of the non-transaction operation request need to be triggered after the preset number threshold of transaction operation requests in the transaction queue are completed, and the periodic scheduling mechanism is used to ensure that the low-priority task obtains an execution opportunity, thereby avoiding interfering with high-priority transaction business while maintaining the functionality and usability of the system.

[0070] Specifically, the execution of the non-transaction operation request can be processed by the transaction intermediary platform, which can include querying corresponding information, login verification, etc., such as verifying whether the login of the user account is abnormal or querying the transaction state of the user, etc.

[0071] Optionally, after the non-trading operation request is executed, a non-trading result response can be obtained as a result feedback to the user end. Specifically, returning the non-trading result response to the user end can be directly returned through the protocol connection relationship between the transaction intermediary platform and the user end by calling the corresponding interface; or the non-trading result response can be put into the response report queue and returned to the user end based on the response report queue.

[0072] Optionally, the non-trading operation request can include a non-trading operation request that does not need to return a non-trading result response, such as a market operation request. Specifically, the transaction platform can actively send the current transaction market message to the transaction intermediary platform based on a preset time interval. The transaction market message does not need to be sent directly to the user end, but only needs to be maintained and updated in the transaction intermediary platform. For users who need to obtain transaction market messages, the corresponding query request can be submitted by the user. Therefore, for the execution of the market operation request, the transaction intermediary platform can update the market message maintained in the transaction intermediary platform based on the corresponding updated market message, without generating a non-trading response.

[0073] In this step, the execution of the non-trading operation request in the non-trading queue is triggered when the number of transaction operation requests reaches the first preset number and the preset time condition is met, so that the transaction intermediary platform can realize flexible scheduling between transaction tasks and non-trading tasks while ensuring the real-time performance of high-priority tasks. At the same time, the system resource waste or response delay caused by non-trading tasks occupying resources is avoided, and the system resources are periodically released to process low-priority non-trading operation requests. The double judgment mechanism of the preset number threshold and the preset time condition is used to control the task switching frequency, which avoids resource waste caused by long-term occupation of the transaction queue and prevents the influence of non-trading tasks on the overall response ability of the system due to long-term non-execution. In a single-thread architecture, the cooperative optimization execution of transaction and non-trading operation requests is realized.

[0074] Step 208: In the case that the number of executed non-trading operation requests reaches the second preset number and the transaction queue is not empty, jump to sequentially take out and execute the transaction operation request from the transaction queue.

[0075] The second preset number is a dynamic switching threshold set in the transaction operation system to control the execution frequency of non-trading operation requests. The value of the first preset number can be determined by a system configuration file or a runtime parameter, which is used to measure the upper limit of processing low-priority tasks in the non-trading queue. Specifically, the setting of the second preset number needs to consider the data integrity requirement of non-trading tasks, the system resource allocation strategy, and the urgency of the tasks to be processed in the transaction queue, to ensure that the resources are released in time to process high-priority transaction operation requests while ensuring the execution of non-trading operation requests.

[0076] Optionally, the second preset number is usually small, for example, the second preset number can be set as 1, that is, in the case of switching to execute the non-transaction queue, only one non-transaction operation request is executed, and then it is immediately returned whether there is a transaction operation request in the polling transaction queue, so as to ensure the priority execution of the transaction queue as much as possible.

[0077] Optionally, in the non-transaction queue, the non-transaction operation request can be stored in the form of a buffer, and a plurality of non-transaction operation requests can be stored in a single buffer block. Therefore, the second preset number can also be determined according to the number of non-transaction operation requests stored in the buffer block.

[0078] In the case of completing the execution of the second preset number of non-transaction operation requests, it is further polled whether the transaction queue is empty. In the case that the transaction queue is not empty, the transaction queue is jumped to execute, that is, the transaction operation request is sequentially taken out from the transaction queue and executed.

[0079] Optionally, in the case that the transaction queue is empty, the step of sequentially taking out the non-transaction operation request from the non-transaction queue and executing it can be triggered again, and in the case that the second preset number of non-transaction operation requests are executed again, it is polled whether the transaction queue is empty.

[0080] In the embodiments of the present specification, by storing the transaction operation requests and the non-transaction operation requests with different execution priorities in the mutually isolated transaction queue and the non-transaction queue respectively, and combining the dynamic switching mechanism of the preset number threshold and the preset time condition, in the case that the transaction queue is not empty, the high-priority transaction operation request is preferentially processed, in the case that the number of transaction operation requests reaches the first preset number and the preset time condition is met, the low-priority non-transaction operation request is actively switched to the non-transaction queue for processing, and in the case that the number of non-transaction operation requests reaches the second preset number, it is immediately returned to the transaction queue, forming a dynamic scheduling mode of circularly and repeatedly, ensuring the priority execution of the transaction operation request and the execution guarantee of the non-transaction operation request, realizing the dynamic balance between resource allocation and task scheduling, taking into account the demand of the overall efficiency of the transaction system and the timeliness of the key business, maintaining the overall response ability of the transaction operation system, reducing the context switching overhead, and realizing the cooperative optimization execution of the transaction operation request and the non-transaction operation request under the single-thread architecture.

[0081] In an optional embodiment of the present specification, when the number of executed transaction operation requests reaches the first preset number and the preset time condition is met, the non-transaction operation requests are sequentially taken out from the non-transaction queue and executed, including: when the number of executed transaction operation requests reaches the first preset number, the current timestamp is obtained; it is judged whether the current timestamp is within the time window, if not, the non-transaction operation requests are sequentially taken out from the non-transaction queue and executed.

[0082] The current timestamp is a system time mark obtained by the transaction operation system at a specific moment, which is used to measure the execution time sequence of the operation request and the trigger condition of the scheduling logic. Since the execution speed of the operation request is very fast, the timestamp can usually be recorded with millisecond or microsecond level precision. The current timestamp is the timestamp after the first preset number of transaction operation requests are completed. Specifically, when the number of transaction operation requests reaches the first preset number, the transaction intermediary platform obtains the current timestamp, and compares the timestamp with the start and end time of the time window to determine whether to trigger the execution process of the non-transaction queue.

[0083] The time window is a dynamic time period set in the transaction operation system to control the execution time of the non-transaction operation request. The start and end time of the time window can be determined by the timestamp of the update market message returned by the transaction platform, so as to ensure that the waiting time of the update market message is not too long to affect the basic response of the transaction operation system. The length of the time window can be dynamically set based on different use scenarios. Optionally, the length of the time window can be determined based on the time interval of the update market message returned by the actual transaction platform, or based on the execution performance of the operation request of the transaction intermediary platform. The present specification does not make specific limitation on this.

[0084] Optionally, the time window can be divided into a first time window and a second time window. Specifically, the first time window can be determined based on the timestamp of the first update market message returned by the transaction platform when the transaction operation request is executed; and the second time window can be determined based on the timestamp of the last update market message returned by the transaction platform after the first preset number of transaction operation requests are executed.

[0085] Exemplarily, in the financial transaction scenario, when a preset number of 100 order placing and / or order canceling transaction operation requests are continuously executed, the current timestamp T=240 ms is obtained and compared with the preset time window [0, 200 ms] to determine whether the current timestamp falls within the time window; T=240 ms exceeds the preset time window, indicating that the execution time of the transaction operation request has exceeded the time window, and the non-transaction queue needs to be executed, so the non-transaction operation requests are sequentially taken out from the non-transaction queue and executed.

[0086] In the embodiments of the present specification, by introducing a dynamic judgment mechanism based on a time window, the transaction intermediary platform can realize the priority execution of high-priority transaction operation requests, avoid transaction delays caused by non-transaction tasks occupying resources, and control the task switching logic through the association of timestamps and time windows to ensure that non-transaction operation requests obtain execution opportunities in non-critical periods. Dynamic time window adjustment can adapt to the resource allocation needs in different transaction scenarios, and realize the balanced optimization between transaction operation requests and non-transaction operation requests under a single-thread architecture.

[0087] In an optional embodiment of the present specification, the transaction operation system further includes a transaction platform, and the time window includes a first time window and / or a second time window. The first time window is determined according to a first timestamp, and the first timestamp is the timestamp at which the transaction platform returns the first updated market information message. The second time window is determined according to a second timestamp, and the second timestamp is the timestamp at which the transaction platform returns the last updated market information message. The current timestamp is determined whether it is within the time window. If not, the non-transaction operation request is triggered to be sequentially taken out from the non-transaction queue and executed, including: determining whether the current timestamp is within the first time window, and if not, triggering the non-transaction operation request to be sequentially taken out from the non-transaction queue and executed; and / or, determining whether the current timestamp is within the second time window, and if not, triggering the non-transaction operation request to be sequentially taken out from the non-transaction queue and executed.

[0088] The transaction platform is in the transaction operation system, responsible for executing transaction instructions and returning transaction results. The transaction platform can include securities exchanges, futures exchanges, foreign exchange trading platforms, etc. in the financial transaction scenario, and can also include e-commerce trading platforms, energy resource trading platforms, etc. The transaction platform can realize uplink and downlink bid communication with the transaction intermediary platform through a preset protocol interface. Specifically, the transaction platform receives transaction operation information sent by the transaction intermediary platform and completes the actual transaction operation, and returns the transaction result. For example, in the financial transaction scenario, when the transaction intermediary platform sends a stock buy order request, the request is submitted to the exchange through the exchange API interface, and the transaction return information is returned to the transaction intermediary platform after the transaction.

[0089] The first time window is a dynamic time period in the transaction operation system for controlling the execution time of non-transaction operation requests. The start time of the first time window can be determined by the timestamp of the first update market message returned by the transaction platform. At the same time, the length of the first time window can be dynamically adjusted based on the intensity of the update market message sent by the transaction platform. Specifically, the first time window can be used to protect the execution of non-transaction operation requests in the non-transaction queue. For example, in the financial transaction scenario, when the transaction platform first sends a stock market update message, the transaction intermediary platform takes the timestamp T1 of the message as the starting point of the first time window, and determines the time interval [T1, T1+250ms] based on T1 and a preset window length (e.g., 250ms). When the current timestamp is within the first time window, the transaction queue is executed, and when the current timestamp is outside the first time window, the non-transaction queue is switched to be executed.

[0090] The second time window is also a dynamic time period in the transaction operation system for controlling the execution time of non-transaction operation requests. The start time of the second time window is determined by the timestamp of the last update market message returned by the transaction platform. The length of the second time window can also be dynamically adjusted based on the intensity of the update market message sent by the transaction platform. Specifically, the second time window can be used to protect the priority processing of high-priority transaction operation requests within the sending time period of the update market message. For example, in the financial transaction scenario, during the execution of the transaction operation request, the transaction platform sends multiple update market messages in parallel. The transaction intermediary platform takes the timestamp T2 of the last market message as the starting point of the second time window, and determines the time interval [T2, T2+150ms] based on T2 and a preset window length (e.g., 150ms). When the current timestamp is within the second time window, the transaction queue is executed, and when the current timestamp is outside the second time window, the non-transaction queue is switched to be executed.

[0091] The first timestamp is the system time marker of the first update market message returned by the transaction platform, which is used to identify the time starting point of the first update market message waiting. The first timestamp is the core basis for the transaction intermediary platform to determine whether to enter the first time window.

[0092] The update market message is a market data packet sent by the transaction platform to update the market message in the transaction intermediary platform. The update market message is usually sent based on a preset time interval (also known as time slice), such as 500ms. The preset time interval can be set according to the real-time market update situation of the transaction platform. The update market message usually includes key fields such as transaction object code, latest price, and trading volume.

[0093] The first update message is the first data packet sent by the trading platform within a specific trading operation request execution period, which can be used to trigger the first time window of the trading operation system and initialize the monitoring logic for the update message. For example, in the financial trading scenario, when the real-time quotation of stock A first changes, the trading platform will generate and send an update message, which can contain the latest transaction price of stock A 100.5 yuan and the transaction volume 1000 hands. The trading intermediary platform can start the timing of the first time window according to the first timestamp of receiving the update message.

[0094] The second timestamp is the system time mark of the last update message returned by the trading platform, which is used to identify the starting point of the waiting time of the last update message. The second timestamp is the core basis for the trading intermediary platform to determine whether to enter the second time window.

[0095] The last update message is the last data packet sent by the trading platform within a specific trading period, which can be used to trigger the second time window of the trading operation system.

[0096] Specifically, the first time window is a time window starting from the first timestamp, which can be understood as the waiting time of the first update message; the second time window is a time window starting from the second timestamp, which can be understood as the waiting time of the last update message. Therefore, in the case of only one update message, the first time window and the second time window are the same.

[0097] Specifically, after determining the first time window and the second time window, the current timestamp can be used for judgment. The judgment basis of the first time window and the second time window is independent of each other, that is, in the case that the current timestamp is not within any time window, the non-trading operation request is sequentially taken out from the non-trading queue and executed.

[0098] Specifically, in the process of executing the first preset number of transaction operation requests, the transaction intermediary platform will simultaneously receive multiple update market information messages from the transaction platform, for example, the update market information messages sent by the transaction platform are generally sent in 500 ms as a slice, at the same time, the transaction intermediary platform will determine the first timestamp T1 based on the receiving time of the first update market information message, and update the second timestamp T2 after the bottom of each update market information message, until the execution of the first preset number of transaction operation requests is completed, the receiving time of the last update market information message in the same slice is determined as the second timestamp T2; based on the preset time length, the first time window (for example, the preset time length of the first time window is 250 ms, and the first time window is [T1, T1+250 ms]) and the second time window (for example, the preset time length of the second time window is 150 ms, and the second time window is [T2, T2+150 ms]) are determined; based on whether the current timestamp is in the first time window or the second time window, it is judged whether to trigger to take out and execute non-transaction tasks.

[0099] Optionally, if the current timestamp is in the first time window and / or the second time window, that is, the first update market information message and / or the last update market information message can still continue to wait, return to the step of sequentially taking out the transaction operation request from the transaction queue and executing until the current timestamp is not in the first time window and / or the second time window, switch to the execution of the non-transaction queue.

[0100] Exemplarily, in the financial transaction scene, in the process of completing the execution of the first preset number of transaction operation requests, the first timestamp T1 of the first update market information message received by the transaction intermediary platform is 09:00:00.000, and the second timestamp T2 of the last update market information message is 09:00:00.150; if the length of the first time window is 250 ms and the length of the second time window is 150 ms, the first time window can be determined as [09:00:00.000, 09:00:00.250], and the second time window is [09:00:00.150, 09:00:00.300]; the current timestamp T of the transaction intermediary platform after completing the first preset number of transaction operation requests is 09:00:00.260, which is in the second time window, but has exceeded the first time window, so the non-transaction operation request is triggered from the non-transaction queue. sequentially take out and execute.

[0101] In the embodiments of the present specification, by further refining the time window into a first time window and a second time window based on the arrival time of each update market message, the transaction intermediary platform can ensure that the processing of the update market message does not exceed the maximum waiting time, while realizing the priority execution of the high-priority transaction operation request, avoiding the transaction delay caused by the non-transaction task occupying resources; through the independent judgment mechanism of the double time window, the balance optimization between the transaction operation request and the non-transaction operation request under the single-thread architecture is realized.

[0102] In an optional embodiment of the present specification, the transaction operation system further comprises a user end; before obtaining the transaction queue and the non-transaction queue, it further comprises: receiving the target operation request sent by the user end; and putting the target operation request into the transaction queue and / or the non-transaction queue.

[0103] The user end is a terminal device or a client in the transaction operation system, which is used to initiate an operation request and receive a response feedback. The user end can be a client software, a mobile terminal application, a web interface, etc. in a financial transaction scenario, or a transaction terminal device in the field of e-commerce, energy resources, etc. The user end can send a transaction operation request (such as a order, a cancel order, etc.) or a non-transaction operation request (such as a query request, a login request, etc.) to the transaction intermediary platform, and receive a transaction return response or a non-transaction result response returned by the transaction intermediary platform.

[0104] The target operation request is a specific operation instruction sent by the user end to the transaction intermediary platform. The type of the target operation request can be determined by the operation content, for example, a high-priority transaction operation request (such as a order, a cancel order) or a low-priority non-transaction operation request (such as an account query, a login verification).

[0105] Specifically, the target operation request can carry an operation classification identifier (such as a function number, etc.) or an operation object (such as a subject matter code), and the transaction intermediary platform can classify and process the target operation request based on the operation classification identifier. For example, in a financial transaction scenario, the target operation request of "buying 100 hands of stock A" submitted by the user can be classified as a transaction operation request; while the target request of "querying the current position" submitted by the user can be classified as a non-transaction operation request.

[0106] Optionally, the transaction intermediary platform and the user end can communicate through a protocol interface. Specifically, the user end can send an operation request to the transaction intermediary platform through the protocol interface, and the transaction intermediary platform can send a transaction return response and / or a non-transaction result response to the user end through the protocol interface.

[0107] Optionally, the protocol interface can include a Transmission Control Protocol (TCP) interface and a User Datagram Protocol (UDP) interface. The Transmission Control Protocol interface can establish a three-way handshake connection to achieve reliable transmission of data in the communication link; the User Datagram Protocol interface can send data packets without establishing a connection to achieve low-latency high-priority data transmission.

[0108] Specifically, the user end sends a target operation request to the transaction intermediary platform through the protocol interface, and the transaction intermediary platform can put the target operation request into a transaction queue and / or a non-transaction queue.

[0109] For example, in a financial transaction scenario, when the user end submits an operation request of "stock B cancel order", the transaction intermediary platform identifies it as a transaction operation request and puts it into the transaction queue; when the user end submits an operation request of "query account balance", the transaction intermediary platform identifies it as a non-transaction operation request and puts it into the non-transaction queue.

[0110] In the embodiments of the present specification, by receiving the target operation request sent by the user end and classifying it into the transaction queue or the non-transaction queue based on the type of the operation request, accurate classification of the operation request is achieved, and by physically isolating the transaction queue and the non-transaction queue, the transaction intermediary platform can divide operation requests of different priorities during the process of receiving the operation request, ensure that the real-time and stability requirements of the transaction operation request are met in priority, and at the same time guarantee the data integrity and system response ability of the non-transaction operation request, so as to realize efficient cooperative execution of the transaction operation request and the non-transaction operation request under the single-thread architecture.

[0111] In an optional embodiment of the present specification, receiving a target operation request includes: receiving a target operation request sent by a user end through a Transmission Control Protocol (TCP) interface; putting the target operation request into a transaction queue and / or a non-transaction queue includes: determining whether the target operation request is a transaction operation request or a non-transaction operation request based on an operation classification identifier of the target operation request; in the case that the target operation request is a transaction operation request, putting the target operation request into the transaction queue; in the case that the target operation request is a non-transaction operation request, putting the target operation request into the non-transaction queue.

[0112] The transmission control protocol interface is a communication protocol interface in the transaction operation system for ensuring reliable data transmission. The transmission control protocol interface realizes communication connection management, data retransmission and sequential delivery based on the transmission control protocol (TCP). Specifically, since the establishment of the transmission control protocol interface requires protocol verification, such as three-way handshake connection, bidirectional communication can be realized, and the reliability of the connection and the sequential nature of data transmission can be ensured. Therefore, the transmission protocol interface can be suitable for scenarios with high requirements for data integrity. For example, in the financial transaction scenario, when a user submits a "buy 100 hands of stocks" transaction operation request through the TCP interface, the transaction intermediary platform will verify the request legality of the protocol connection, ensure the smooth suggestion of the communication connection based on the confirmation mechanism of the TCP protocol, and thus complete the complete reception of the operation request, avoiding data loss or out-of-order.

[0113] The operation classification identifier is a judgment basis for distinguishing transaction operation requests from non-transaction operation requests in the transaction operation system. The operation classification identifier can include a function number, an operation object or other preset field forms embedded in the target operation request.

[0114] Specifically, the operation classification identifier defines the priority and processing logic of the operation request through a preset rule, for example, identifying "order" and "cancel order" operation requests as transaction operation requests, and identifying "query" and "login" requests as non-transaction operation requests.

[0115] After determining the operation request type of the target operation request, the target operation request can be placed in the corresponding queue. Specifically, since the communication of the transmission control protocol interface is bidirectional, the transaction intermediary platform can return the transaction return answer of the transaction operation result and / or the non-transaction result answer of the non-transaction operation result to the user end through the transmission control protocol interface.

[0116] Optionally, before determining whether the target operation request is a transaction operation request or a non-transaction operation request based on the operation classification identifier of the target operation request, the target operation is thread positioned.

[0117] Specifically, a thread is the smallest unit of program execution in an operating system, an independent execution stream within a process, and can execute multiple tasks concurrently. Threads can share the resources of the process to which they belong (such as memory space, file handles, etc.), but have independent program counters, register sets, and stacks. Due to the lightweight nature of threads, they are highly efficient to schedule and are suitable for scenarios that require high concurrency or real-time response. Thread positioning is the process of mapping a specific operation request to a suitable thread, aiming to optimize resource allocation and task execution efficiency. In a transaction operating system, thread positioning can determine which thread to handle a received operation request based on pre-set positioning rules or strategies (such as priority division, user identity division, etc.). For example, transaction operation requests can be positioned to threads in a high-priority thread pool, while non-transaction operation requests can be assigned to low-priority threads. Based on different user identities, target operation requests sent by each user through a Transmission Control Protocol interface can also be positioned to independent threads to avoid mutual interference between users. Thread positioning ensures the real-time performance of critical tasks and the stability of the entire system by reasonably allocating thread resources.

[0118] For example, in a financial transaction scenario, the operation request "stock B cancel order" submitted by the user terminal carries the function number "T003", and the transaction intermediary platform identifies it as a transaction operation request and places it in the transaction queue based on the pre-set correspondence between function numbers and operation categories. The "query account balance" request submitted by the user terminal carries the function number "Q004", and the transaction intermediary platform identifies it as a non-transaction operation request and places it in the non-transaction queue based on the pre-set correspondence between function numbers and operation categories.

[0119] In the embodiments of the present specification, by receiving the target operation request sent by the user terminal through the Transmission Control Protocol interface and based on the classification logic of the operation classification identifier, accurate classification of the target operation request is achieved, ensuring the integrity and sequence of execution for transaction operation requests and accurate classification and resource allocation for non-transaction operation requests, thereby achieving efficient collaborative execution of transaction operation requests and non-transaction operation requests under a single-thread architecture.

[0120] In an optional embodiment of the present specification, receiving a target operation request includes receiving a target operation request sent by a user terminal through a User Datagram Protocol interface; and placing the target operation request in a transaction queue and / or a non-transaction queue includes placing the target operation request in the transaction queue.

[0121] The user datagram protocol interface is a communication protocol interface for realizing low-delay data transmission in the transaction operation system. The user datagram protocol interface realizes connectionless datagram transmission based on the user datagram protocol. Specifically, since the user datagram protocol interface can directly send data packets without establishing a connection with the transaction intermediary platform, it can be applied to a data transmission scenario with extremely high real-time requirements.

[0122] Specifically, since the transmission of the user datagram protocol interface is unidirectional and unordered, the operation requests transmitted through the user datagram protocol interface are all transaction operation requests, and thus it is not necessary for the transaction intermediary platform to perform classification and identification, but to directly put the target operation request sent through the user datagram protocol interface into the transaction queue.

[0123] Further, for the transaction operation request sent through the user datagram protocol interface, since the user datagram protocol interface cannot perform reverse data transmission, the corresponding transaction result response of the transaction operation request can be returned to the user end through the transmission control protocol interface.

[0124] Optionally, the reception of the user datagram protocol interface can be based on the cache of the transaction intermediary platform itself, without storage and reading through external storage, further improving the timeliness of the execution of the transaction operation request.

[0125] Optionally, since there is no identity verification operation step in the transmission process of the user datagram protocol interface, the user end can be limited in terms of authority, that is, the user end needs to have the use authority of the user datagram protocol interface to send the transaction operation request through the user datagram protocol interface.

[0126] For example, in a financial transaction scenario, when the user end sends a "stock C cancel order" operation request through the user datagram protocol interface, the transaction intermediary platform can immediately receive the target operation request and put it into the transaction queue through the internal cache, without waiting for the establishment and verification of the communication link.

[0127] In the embodiments of the present specification, by receiving the target operation request sent by the user end through the user datagram protocol interface, without establishing and verifying the communication link, by directly putting the target operation request into the transaction queue, the instant response to the high-priority transaction operation request in the high-frequency transaction scenario is realized, the overhead of establishing and maintaining the communication link is reduced, the data transmission delay for the transaction operation request is reduced, and the key transaction operation request is ensured to be executed preferentially in the single-thread architecture, so as to ensure the real-time performance while optimizing the dynamic allocation efficiency of system resources.

[0128] In an optional embodiment of the present specification, the transaction operation system further comprises a transaction platform; triggering the transaction operation requests in the transaction queue to be sequentially taken out and executed, comprising: sequentially taking out the transaction operation requests in the transaction queue; processing the transaction operation requests to obtain transaction operation information, and sending the transaction operation information to the transaction platform; receiving the transaction result return of the transaction operation information returned by the transaction platform.

[0129] The transaction operation information is a standardized data packet generated by the transaction intermediary platform after receiving and processing the transaction operation request, which is used to deliver specific transaction instructions or operation requirements to the transaction platform. Specifically, the transaction operation information can include transaction target code, transaction direction (buy / sell), quantity, price and other key fields, and is packaged based on the protocol format supported by the transaction platform. For example, in the financial transaction scenario, when the user submits a transaction operation request of "buying 500 hands of stock D", the transaction intermediary platform will first verify the user's authority and account balance, and convert the request into a transaction operation information format that meets the API interface requirements of the transaction market, such as a data packet containing stock code "D", transaction direction "buy", quantity "500" and price "100.2 yuan", so as to execute the actual transaction operation by the transaction platform.

[0130] The transaction result return is a transaction result data packet fed back by the transaction platform to the transaction intermediary platform after completing the actual execution of the transaction operation information. Specifically, the transaction result return can include transaction status (transaction / deletion / failure), transaction price, transaction quantity, transaction time and other fields, which are used to confirm the final execution of the transaction operation. For example, in the financial transaction scenario, when the transaction platform successfully executes the buy request of stock D, it will return a transaction result return indicating that the transaction is completed at 100.2 yuan for 500 hands, and the transaction time stamp "14:30:45" can be recorded, and the transaction intermediary platform updates the user account status accordingly and generates a corresponding transaction return answer to return to the user end.

[0131] Specifically, the transaction intermediary platform and the transaction platform can transmit data through a preset interface for uplink and downlink quotation, that is, the transaction intermediary platform uplinks the transaction operation information to the transaction platform, and the transaction platform downlinks the transaction result return to the transaction intermediary platform.

[0132] Optionally, in the process of the transaction mediation platform sending the transaction operation information to the transaction platform, seat verification can be performed. Specifically, the seat is a unique credential in the transaction operation system for identifying the legal identity and authority of the transaction mediation platform in the transaction platform. The seat is usually allocated by the transaction platform (such as a stock exchange) and represents the participation qualification and operation authority of the transaction mediation platform in a specific transaction market. Seat verification is a legal verification step completed by the transaction mediation platform before sending the transaction operation information to the transaction platform to ensure that the initiator of the transaction request has a legal transaction qualification. For example, in a financial transaction scenario, a transaction mediation platform of a certain securities company needs to hold a seat number "S12345" allocated by the exchange, and when sending a stock buy order request, the seat number must be attached, otherwise the transaction platform will regard it as an illegal request and refuse to execute it.

[0133] In the embodiments of the present specification, by taking out the transaction operation request from the transaction queue and converting the transaction operation request into standardized transaction operation information sent to the transaction platform, the transaction mediation platform can accurately schedule and efficiently execute high-priority transaction tasks, ensuring that the instructions of the transaction operation request can strictly follow the preset timing logic and protocol specification to complete the uplink offer; at the same time, by receiving the transaction result return returned by the transaction platform, the transaction mediation platform can update the execution status of the transaction operation request in real time and generate a feedback response, ensuring the integrity of the transaction operation and the system response ability, thereby realizing closed-loop control of the transaction process and dynamic optimization of resource allocation under a single-thread architecture.

[0134] In an optional embodiment of the present specification, the transaction operation system further includes a user end; after receiving the transaction result return returned by the transaction platform for the transaction operation information, it further includes: constructing a transaction return request and putting the transaction return request into the transaction queue; in the case of taking out and executing the transaction return request, processing the transaction result return to obtain a transaction return response; putting the transaction return response into the response return queue; in the case of taking out the transaction return response from the response return queue, returning the transaction return response to the user end.

[0135] The transaction return request is an operation request generated by the transaction mediation platform after receiving the transaction result return returned by the transaction platform for feeding back the transaction result to the user end. The transaction return request is also a high-priority operation request, and the transaction return request is a secondary request of the transaction operation request, so after the transaction return request is constructed, the transaction return request can be put into the transaction queue.

[0136] Specifically, the transaction response request can include identification information of the transaction result response, so as to identify the corresponding transaction result response, so that the transaction mediation platform can process the corresponding transaction result response in the process of taking out and executing the transaction response request from the transaction queue. Optionally, the transaction response request can also include the identification of the corresponding user terminal or the request sequence number, so as to ensure the correspondence between the transaction result and the original request.

[0137] The transaction response reply is the final feedback information returned by the transaction mediation platform to the user terminal after processing the corresponding transaction result response in the process of taking out and executing the transaction response request.

[0138] Specifically, the transaction response reply can be formatted and packaged based on the core data in the transaction result response, and auxiliary information such as system processing timestamp and state description can also be added to fully present the transaction result. For example, in the financial transaction scenario, the transaction mediation platform processes the completed transaction operation request of stock D, returns the transaction result response and constructs the transaction response request, and generates the transaction response reply based on the transaction result response in the process of executing the transaction response request. The content can include "Your stock D buy order has been completed, the transaction price is 100.2 yuan, the transaction quantity is 500 hands, and the transaction time is 14:30:45", and the system processing timestamp "14:30:48" is attached for the user terminal to display.

[0139] The response reply queue is a buffer queue in the transaction operation system for temporarily storing transaction response replies, used to decouple the generation and sending process of the transaction response reply, and ensure the order of transaction result feedback and the stability of system response.

[0140] Specifically, the response reply queue can follow the first-in first-out principle, cache the transaction response reply according to the execution order of the transaction response request, and take out and return to the user terminal piece by piece when the transaction operation system is dispatched to the sending stage.

[0141] Optionally, since the communication link between the transaction mediation platform and the user terminal can be established through the TCP interface, the transaction response reply returned to the user terminal can be returned through the TCP interface.

[0142] Optionally, in addition to the transaction response reply corresponding to the transaction operation request, the transaction mediation platform also needs to return the non-transaction result reply corresponding to the non-transaction operation request to the user terminal, so the response reply queue can also put the non-transaction result reply and return it to the user terminal through the TCP interface.

[0143] Exemplarily, in a financial transaction scenario, when the transaction platform returns a successful order cancellation response of stock E, the transaction intermediary platform constructs a transaction response request based on the transaction result response and puts it into the transaction queue; in the process of taking out and executing the transaction response request from the transaction queue, the key information "order number ORD12345" "order cancellation status success" and the like in the transaction result response can be targeted, and the transaction response answer "Your order ORD12345 has been successfully cancelled" is generated in combination with the user end identifier "ClientX", and the system processing timestamp "15:00:30" is attached to ensure that it is returned to the correct user end subsequently; the generated transaction response answer is put into the response queue, waiting for the scheduling of the transaction intermediary platform; in the process of triggering the execution of the response queue, the transaction intermediary platform will take out the transaction response answer one by one, and return it to the corresponding user end through the preset protocol interface (such as the TCP interface), to complete the closed-loop feedback of the transaction result.

[0144] In the embodiments of the present specification, by constructing a transaction response request based on the transaction result response returned by the transaction platform and putting it into the transaction queue, the ordered scheduling and high-priority processing of the transaction result feedback are realized, and it is ensured that the transaction response answer can be generated strictly in accordance with the preset timing logic; by temporarily storing the transaction response answer in the response queue and returning it to the user end, the integrity of the transaction result feedback and the stability of the system response are further ensured, so that the closed-loop control of the transaction process and the dynamic optimization of the resource allocation are realized under the single-thread architecture.

[0145] In an optional embodiment of the present specification, the transaction operation system further comprises a user end; triggering the sequential taking out and execution of the non-transaction operation request from the non-transaction queue comprises: sequentially taking out and executing the non-transaction operation request from the non-transaction queue to obtain a non-transaction result response; putting the non-transaction result response into the response queue; in the case of taking out the non-transaction result response from the response queue, returning the non-transaction result response to the user end.

[0146] The non-transaction result response is feedback information generated by the transaction intermediary platform after executing the non-transaction operation request, which is used to deliver the execution result of the non-transaction operation to the user end. Specifically, the non-transaction result response can include the processing status (such as success / failure) of the non-transaction operation request, related data (such as account balance, position information, etc.) and system processing timestamp, etc., to ensure that the user end can accurately obtain the operation result. For example, in a financial transaction scenario, when the user submits a non-transaction operation request of "querying account balance", the transaction intermediary platform will verify the user's authority and query the account information, generate a non-transaction result response, which can include "Your account balance is 500,000 yuan, query time 15:10:20", for the user end to display.

[0147] Specifically, since the execution of the non-transaction operation request does not need to pass through the transaction platform processing, there is no intermediate transition data, and the transaction mediation platform can directly execute the non-transaction operation request and obtain a non-transaction result response.

[0148] Specifically, since the priority of the returned non-transaction result response is low, a corresponding secondary operation request does not need to be generated based on the non-transaction result response and placed in the transaction queue, so as to avoid affecting the execution of the high-priority transaction operation request or transaction return request.

[0149] Specifically, the obtained non-transaction result response also needs to be returned to the user end, and therefore, the non-transaction result response can also be placed in the response return queue and returned to the user end in the case of taking out. The method operation of taking out and returning the non-transaction result response can refer to the foregoing embodiment of returning the transaction return response, which will not be described herein again.

[0150] Exemplarily, in the financial transaction scenario, when the user end submits a non-transaction operation request of "querying the current position", the transaction mediation platform performs user identity verification, and in the case of passing the verification, retrieves the position record of the user end from the database of the transaction mediation platform, and generates a position information table based on the position data as a non-transaction result response; in the case of obtaining the non-transaction result response, the non-transaction result response can be placed in the response return queue; in the execution stage of the response return queue, the transaction mediation platform takes out the non-transaction result response piece by piece, and returns to the corresponding user end through a preset protocol interface (such as a TCP interface), to complete the closed-loop feedback of the operation result.

[0151] In the embodiments of the present specification, by sequentially taking out the non-transaction operation request from the non-transaction queue and executing, obtaining the non-transaction result response, and placing the non-transaction result response in the response return queue, the ordered processing of the low-priority non-transaction task is realized, and it is ensured that the execution of the non-transaction operation request will not interfere with the real-time performance of the high-priority transaction operation task; by placing the non-transaction result response in the response return queue and returning to the user end based on the preset protocol interface, the generation and feedback process of the operation result is further decoupled, the integrity of the non-transaction operation result and the stability of the system response are guaranteed, so that the efficient execution of the non-transaction task and the dynamic optimization allocation of resources are realized under the single-thread architecture.

[0152] In an optional embodiment of the present specification, the transaction operation system further comprises a transaction platform, and the non-transaction operation request comprises a market operation request; before sequentially taking out the non-transaction operation request from the non-transaction queue and executing, further comprising: receiving an updated market message sent by the transaction platform; constructing a market operation request based on the updated market message, and putting the market operation request into the non-transaction queue; triggering the sequential taking out and execution of the non-transaction operation request from the non-transaction queue, comprising: triggering the taking out and execution of the market operation request from the non-transaction queue, and updating the market message in the transaction intermediary platform based on the updated market message.

[0153] The updated market message is a real-time market data packet sent by the transaction platform to the transaction intermediary platform. Specifically, the updated market message can include the latest price, trading volume, bid and ask of the transaction object, and other key information, which is used to drive the dynamic update of the market data in the transaction intermediary platform. The updated market message can be transmitted through the data transmission link established between the transaction platform and the transaction intermediary platform through the preset interface. The updated market message can be used as an input data source of the market operation request to ensure that the transaction intermediary platform can respond to market changes in a timely manner. The sending of the updated market message can be performed at a preset time interval. For example, in a financial transaction scenario, when the transaction price of stock B changes from 100 yuan to 101 yuan, the transaction platform generates and sends an updated market message containing the latest price, trading volume and timestamp of stock B, and the transaction intermediary platform updates the local market database accordingly to ensure that subsequent transaction operations are based on the latest market information.

[0154] The market operation request is a non-transaction operation request generated in the transaction operation system based on the updated market message sent by the transaction platform, which is used to trigger the synchronization update of the local market data in the transaction intermediary platform.

[0155] Specifically, since the update of the market message in the transaction intermediary platform has a lower demand for real-time, the market operation request constructed based on the updated market message is a non-transaction operation request, and is put into the non-transaction operation queue after being constructed. For example, when the transaction platform pushes the latest price change information of stock A, the transaction intermediary platform will construct a market operation request based on the updated market message and put it into the non-transaction operation queue; during the process of taking out and executing the market operation request from the non-transaction operation queue, the real-time price of stock A stored in the transaction intermediary platform is updated, so that the user end or other system modules can obtain the latest market data.

[0156] Optionally, although the execution priority of the market operation request is lower than that of the transaction operation request and it is put into the non-transaction operation queue, it still needs to update the market message in the transaction intermediary platform in a timely manner, so during the process of executing the transaction operation request preferentially, a time window needs to be determined based on the arrival time of the updated market message, so as to realize the balance of scheduling.

[0157] Exemplarily, when the transaction platform pushes an updated market message of stock C, which contains fields such as "stock code C", "latest price 105.3 yuan", "trading volume 2000 hands", etc., the transaction intermediary platform will construct a market operation request upon receiving the updated market message. The market operation request can contain the same subject code and updated market data, and is additionally attached with a timestamp to identify the timeliness of the message, for updating the market message in the transaction intermediary platform during execution; upon taking out and executing the market operation request from the non-transaction queue, the transaction intermediary platform will update the local stored price of stock C from 104.8 yuan to 105.3 yuan, and synchronously update the trading volume field to 2000 hands, ensuring that subsequent transaction operations (such as order placement and order cancellation) are based on the latest market state.

[0158] In the embodiments of the present specification, by receiving the updated market message sent by the transaction platform and constructing the market operation request, the market operation request is put into the non-transaction queue, and upon taking out and executing the market operation request, the market message in the transaction intermediary platform is updated based on the updated market message, realizing real-time response to market dynamics, ensuring that the local market data is synchronized with the transaction platform; under the premise of ensuring the execution of high-priority transaction operation requests, the market update task is efficiently processed, avoiding the delay of market message update due to too long waiting time, thereby realizing the integrity of transaction data and dynamic optimization allocation of system resources under single-thread architecture.

[0159] The following describes the embodiments of the present specification in conjunction with the accompanying Figure 4 to the accompanying Figure 5 The operation request execution method provided by the present specification is further described by taking the application of the operation request execution method in the financial transaction scenario as an example. Among them, Figure 4 Fig. 1 shows a processing framework schematic diagram of an operation request execution method provided by an embodiment of the present specification, Figure 5 Fig. 2 shows a processing process flow chart of an operation request execution method provided by an embodiment of the present specification. Specifically, for the processing framework as shown in Figure 4 may include the following steps as shown in Figure 5 .

[0160] Step 502: receiving the target operation request sent by the user end through the TCP interface through the TCP service module, and receiving the target operation request sent by the user end through the UDP interface through the UDP service module.

[0161] Step 504: In the TCP service module, the connection break processing and the request message processing are performed for the target operation request sent by the TCP interface, and the target operation request is put into the transaction queue and / or the non-transaction queue through thread positioning, wherein the transaction queue and the non-transaction queue belong to the working thread.

[0162] Step 506: In the UDP service module, the target operation request sent by the UDP interface is put into the transaction queue.

[0163] After step 506 is executed, steps 508 to 512, and / or step 514, and / or steps 516 to 518 are executed.

[0164] Step 508: The transaction operation request is sequentially taken out from the transaction queue, and the transaction business processing is performed, and the transaction operation request is sent to the exchange through the asynchronous multi-thread uplink offer after the seat verification.

[0165] Step 510: The return processing returned by the exchange through the downlink offer is received, and the corresponding transaction return request is generated and put into the transaction queue.

[0166] Step 512: The transaction return request is taken out from the transaction queue, and the return business processing is performed, and the transaction result return response is put into the response return queue, wherein the response return queue belongs to the TCP service thread.

[0167] Step 514: The non-transaction operation request is taken out from the non-transaction queue, and the non-transaction business processing is performed, and the non-transaction result response is obtained and put into the response return queue.

[0168] Step 516: The update market message sent by the exchange through the market offer using the market frequency reduction offer framework is received, and the market operation request is constructed and put into the non-transaction queue.

[0169] Step 518: The market operation request is taken out from the non-transaction queue and executed, and the market message in the transaction intermediary platform is updated based on the update market message.

[0170] Step 520: The transaction return response and / or the non-transaction result response in the response return queue is returned to the user end through the TCP interface.

[0171] In the embodiments of the present specification, by combining the reliability of the TCP interface and the low delay characteristics of the UDP interface, the transaction operation system can simultaneously meet the instant response of high-priority transaction tasks and the orderly processing of non-transaction tasks; by binding the transaction queue and the non-transaction queue to the dedicated thread pool, and combining the thread positioning mechanism, the real-time performance of the key transaction operation and the stability of the non-transaction task are ensured; the asynchronous multi-thread uplink bid and market price reduction bid framework effectively reduces the system resource occupation, and at the same time, through the seat verification and market data update closed loop, the compliance of transaction execution and the synchronization of market information are guaranteed; the hierarchical architecture design and protocol adaptation strategy realize the differentiated processing and dynamic resource allocation of transaction operation requests and non-transaction operation requests, through the unified scheduling of the response report queue, the feedback of transaction return response and non-transaction result response is realized, so that the efficient closed loop control of the transaction process and the dynamic optimization allocation of system resources are realized under the single thread architecture.

[0172] Corresponding to the method embodiments described above, the present specification also provides a transaction operation system embodiment, Figure 6 The structure of a transaction operation system provided by one embodiment of the present specification is shown. As shown in Figure 6 The device comprises:

[0173] The device comprises:

[0174] The user terminal 602 is configured to send a transaction operation request or a non-transaction operation request to the transaction intermediary platform 604, and receive a transaction return response or a non-transaction result response returned by the transaction intermediary platform 604;

[0175] The transaction intermediary platform 604 is configured to obtain a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; trigger the transaction operation request in the transaction queue to be sequentially taken out and executed; in the case that the number of executed transaction operation requests reaches a first preset number and a preset time condition is met, trigger the non-transaction operation request in the non-transaction queue to be sequentially taken out and executed, wherein the execution priority of the non-transaction operation request is lower than that of the transaction operation request; in the case that the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, trigger the transaction operation request in the transaction queue to be sequentially taken out and executed;

[0176] The transaction platform 606 is configured to receive the transaction operation information sent by the transaction intermediary platform 604 and return the transaction result report;

[0177] The transaction platform 606 is further configured to send an updated market message to the transaction intermediary platform 604.

[0178] The user terminal is a terminal device or client in the transaction operation system, which is used to initiate operation requests and receive feedback. The user terminal can be a client software, a mobile application, a web interface in a financial transaction scenario, or a transaction terminal device in the field of e-commerce and energy resources. The user terminal can send transaction operation requests (such as order placement, order cancellation, etc.) or non-transaction operation requests (such as query requests, login requests, etc.) to the transaction intermediary platform, and receive transaction return responses or non-transaction result responses returned by the transaction intermediary platform.

[0179] The transaction intermediary platform is the core scheduling module of the transaction operation system, which is used to obtain transaction queues and non-transaction queues, and sequentially take out and execute operation requests in the queues according to preset rules. Optionally, the transaction intermediary platform can receive operation requests and put them into corresponding queues according to the request type. The transaction intermediary platform processes high-priority transaction operation requests in the transaction queue through an independent thread, and periodically switches to process low-priority requests in the non-transaction queue, to ensure the timeliness of critical business.

[0180] The transaction platform is a transaction operation system that is responsible for executing transaction instructions and returning transaction results. The transaction platform can include securities exchanges, futures exchanges, foreign exchange trading platforms, and e-commerce trading platforms, energy resource trading platforms, etc. The transaction platform can realize uplink and downlink order communication with the transaction intermediary platform through a preset protocol interface. Specifically, the transaction platform receives transaction operation information sent by the transaction intermediary platform and completes the actual transaction operation, and returns the transaction result.

[0181] In the embodiments of the present specification, the transaction intermediary platform stores operation requests in the transaction queue and the non-transaction queue through thread positioning, ensuring exclusive processing of high-priority transaction operation requests; dynamically controls queue switching through a preset number threshold, avoiding resource waste caused by long-term exclusive use of the transaction queue, and preventing non-transaction tasks from affecting the overall response ability of the system due to long-term non-execution; refines the switching logic of the execution queue through the time window mechanism, ensuring that transaction tasks are processed first, and non-transaction operation requests are executed when market data is updated to avoid long waiting time, realizing differentiated processing and dynamic resource allocation of transaction operation requests and non-transaction operation requests, precise feedback of transaction results and non-transaction results through unified scheduling of the response return queue and reliable transmission of the TCP interface, thereby achieving efficient closed-loop control of the transaction process and dynamic optimization of system resources under a single-thread architecture, taking into account the timeliness of critical transaction tasks and the stability of non-transaction tasks.

[0182] Optionally, the transaction intermediary platform further includes a request scheduling module, a request execution module, and an uplink and downlink module.

[0183] The request scheduling module is configured to receive the operation request sent by the user end and put the operation request into a transaction queue or a non-transaction queue.

[0184] The request execution module is configured to sequentially take out the transaction operation request from the transaction queue and execute the transaction operation request, trigger sequentially taking out the non-transaction operation request from the non-transaction queue and executing the non-transaction operation request when the number of executed transaction operation requests reaches a first preset number, and jump to sequentially take out the transaction operation request from the transaction queue and execute the transaction operation request when the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty.

[0185] The uplink and downlink module is configured to send the transaction operation message to the transaction platform and receive the transaction result returned by the transaction platform.

[0186] The uplink and downlink module is further configured to receive the update market information message sent by the transaction platform.

[0187] The request scheduling module is a core component of the transaction intermediary platform responsible for receiving and classifying operation requests, and is configured to distribute the operation requests to corresponding transaction queues or non-transaction queues according to the types of the operation requests. Specifically, the request scheduling module determines the priority and processing logic of the operation request by analyzing the operation classification identifier in the operation request sent by the user end, and distributes the transaction operation request to the transaction queue and the non-transaction operation request to the non-transaction queue based on a preset rule.

[0188] The request execution module is a core execution unit of the transaction intermediary platform responsible for dynamically scheduling and executing operation requests, and is configured to sequentially take out the transaction operation request from the transaction queue and execute the transaction operation request, and control the switching between the transaction queue and the non-transaction queue based on a preset number threshold. Specifically, when the number of transaction operation requests reaches a first preset number, the request execution module will actively trigger the execution process of the non-transaction queue to release system resources and ensure the response ability of low-priority tasks; when the number of non-transaction operation requests reaches a second preset number and the transaction queue is not empty, the request execution module will immediately jump back to the transaction queue to prioritize processing high-priority transaction operation requests.

[0189] The uplink and downlink module is a core communication component of the transaction intermediary platform responsible for data interaction with the transaction platform, configured to send the transaction operation information to the transaction platform and receive the transaction result returned by the transaction platform; and the uplink and downlink module is further configured to receive the update market information message sent by the transaction platform. Specifically, the uplink and downlink module establishes a connection with the transaction platform through a preset interface, completes seat verification, data packaging and sending of the transaction operation request, and receives the downlink return based on the interface of the transaction house.

[0190] In the embodiments of the present specification, the request scheduling module ensures the physical isolation of transaction and non-transaction tasks by operation classification identification analysis and queue allocation, and avoids low-priority operation requests from blocking and interfering with high-priority operation requests; the request execution module realizes the cyclic processing of transaction queues and non-transaction queues under a single-thread architecture by combining a dynamic switching mechanism based on a preset number threshold with time window judgment logic, and takes into account the real-time performance of high-priority tasks and the response capability of low-priority tasks; the uplink and downlink module guarantees the reliability of transaction instructions and the synchronicity of market information through standardized uplink and downlink bidding and market receiving mechanisms; and the precise classification, dynamic scheduling and efficient execution of operation requests in the transaction operation system are realized, and the system resource allocation is optimized.

[0191] The above is a schematic scheme of a transaction operation system according to an embodiment of the present specification. It should be noted that the technical scheme of the transaction operation system and the technical scheme of the operation request execution method described above belong to the same concept, and the details of the technical scheme of the transaction operation system that are not described in detail can be referred to the description of the technical scheme of the operation request execution method.

[0192] Figure 7 A structural block diagram of a computing device 700 according to an embodiment of the present specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 through a bus 730, and a database 750 is used to save data.

[0193] The computing device 700 also includes an access device 740 that enables the computing device 700 to communicate via one or more networks 760. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or combinations of such networks, such as the Internet. The access device 740 can include one or more of any type of network interface (for example, a network interface card (NIC)) such as a wired or wireless Ethernet adapter, a Global System for Mobile Communications (GSM) adapter, a Worldwide Interoperability for Microwave Access (Wi-MAX) adapter, an Ethernet adapter, a Universal Serial Bus (USB) adapter, a cellular network adapter, a Bluetooth adapter, a Near Field Communication (NFC) adapter.

[0194] In one embodiment of the present specification, the above-mentioned components of the computing device 700 and other components not shown in the Figure 7 may be connected to each other, for example, through a bus. It should be understood that Figure 7 The computing device structure diagram shown is only for the purpose of example, and is not a limitation on the scope of the present specification. Those skilled in the art can add or replace other components as needed.

[0195] The computing device 700 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (for example, a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, and the like), a mobile phone (for example, a smartphone), a wearable computing device (for example, a smart watch, smart glasses, and the like), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 700 can also be a mobile or stationary server.

[0196] The processor 720 is configured to execute computer programs / instructions that implement the steps of the above-mentioned operation request execution method when the computer programs / instructions are executed by the processor.

[0197] The above is a schematic solution of the computing device of the embodiment. It should be noted that the technical solution of the computing device and the technical solution of the operation request execution method described above belong to the same concept, and the details of the technical solution of the computing device that are not described in detail can be referred to the description of the technical solution of the operation request execution method.

[0198] An embodiment of the present specification further provides a computer readable storage medium storing computer programs / instructions, which, when executed by a processor, implement the steps of the operation request execution method described above.

[0199] The above is a schematic solution of the computer readable storage medium of the embodiment. It should be noted that the technical solution of the storage medium and the technical solution of the operation request execution method described above belong to the same concept, and the details of the technical solution of the storage medium that are not described in detail can be referred to the description of the technical solution of the operation request execution method.

[0200] An embodiment of the present specification further provides a computer program product comprising computer programs / instructions, which, when executed by a processor, implement the steps of the operation request execution method described above.

[0201] The above is a schematic solution of the computer program of the embodiment. It should be noted that the technical solution of the computer program and the technical solution of the operation request execution method described above belong to the same concept, and the details of the technical solution of the computer program that are not described in detail can be referred to the description of the technical solution of the operation request execution method.

[0202] The foregoing description of specific embodiments of this specification describes the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are possible or may be advantageous. The computer instructions include computer program code, which may be in source code form, object code form, executable files, or some intermediate form. The computer-readable medium may include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a removable hard drive, a magnetic disk, an optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunications signals, and software distribution media. It should be noted that the content of the computer-readable medium may be appropriately expanded or reduced based on the requirements of patent practice. For example, in some jurisdictions, according to patent practice, computer-readable media does not include electrical carrier signals or telecommunications signals.

[0203] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited to the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for the embodiments of this specification. In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0204] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for executing an operation request, characterized in that: A transaction intermediary platform applied to a transaction operating system, the method comprising: Acquire a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; Triggering to sequentially retrieve transaction operation requests from the transaction queue and execute them; When the number of executed trading operation requests reaches a first preset number and a preset time condition is satisfied, triggering the sequential retrieval of non-trading operation requests from the non-trading queue and executing them, wherein the execution priority of the non-trading operation requests is lower than that of the trading operation requests. The preset time condition is determined based on: determining whether the current timestamp of the completion of the execution of the first preset number of trading operation requests falls within a dynamic time window defined by the market update message returned by the trading platform; When the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, the transaction operation requests are sequentially retrieved from the transaction queue and executed.

2. The method according to claim 1, characterized in that The triggering, when the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, to sequentially retrieve and execute non-transaction operation requests from the non-transaction queue includes: When the number of executed transaction operation requests reaches a first preset number, obtaining a current timestamp; It is determined whether the current timestamp is within the time window. If not, it is triggered to sequentially retrieve non-transaction operation requests from the non-transaction queue and execute them.

3. The method according to claim 2, characterized in that The trading operating system further includes a trading platform, the time window includes a first time window and / or a second time window, the first time window is determined according to a first timestamp, which is the timestamp of the first updated market information returned by the trading platform, and the second time window is determined according to a second timestamp, which is the timestamp of the last updated market information returned by the trading platform; The determining whether the current timestamp is within the time window, and if not, triggering sequentially retrieving and executing non-transaction operation requests from the non-transaction queue, includes: Determining whether the current timestamp is within a first time window, and if not, triggering sequentially retrieving and executing non-transaction operation requests from the non-transaction queue; And / or, determining whether the current timestamp is within a second time window; if not, triggering sequentially retrieving and executing non-transaction operation requests from the non-transaction queue.

4. The method according to claim 1, wherein The transaction operating system further includes a user terminal; Before obtaining the transaction queue and the non-transaction queue, the following steps are also included: receiving a target operation request sent by the user terminal; The target operation request is placed in the transaction queue and / or the non-transaction queue.

5. The method according to claim 4, characterized in that The receiving a target operation request includes: receiving a target operation request sent by the user terminal through a transmission control protocol interface; Placing the target operation request into the transaction queue and / or the non-transaction queue includes: determining, based on the operation classification identifier of the target operation request, whether the target operation request is a transaction operation request or a non-transaction operation request; In a case where the target operation request is a transaction operation request, placing the target operation request into the transaction queue; In a case where the target operation request is a non-transaction operation request, the target operation request is placed in the non-transaction queue.

6. The method according to claim 4, characterized in that The receiving a target operation request includes: Receiving a target operation request sent by the user terminal through a user datagram protocol interface; Placing the target operation request into the transaction queue and / or the non-transaction queue includes: Put the target operation request into the transaction queue.

7. The method according to any one of claims 1 to 6, characterized in that The transaction operating system also includes a transaction platform; The triggering sequentially extracts and executes transaction operation requests from the transaction queue, including: Sequentially taking out transaction operation requests from the transaction queue; Processing the transaction operation request, obtaining transaction operation information, and sending the transaction operation information to the transaction platform; Receive a transaction result report for the transaction operation information returned by the transaction platform.

8. The method according to claim 7, characterized in that The transaction operating system further includes a user terminal; After receiving the transaction result report for the transaction operation information returned by the transaction platform, the method further includes: Constructing a transaction report request and placing the transaction report request into the transaction queue; When the transaction report request is retrieved and executed, the transaction result report is processed to obtain a transaction report response; Put the transaction return response into a response return queue; When the transaction report response is taken out from the response report queue, the transaction report response is returned to the user end.

9. The method according to claim 1, characterized in that The transaction operating system further includes a user terminal; The triggering sequentially extracts and executes non-transaction operation requests from the non-transaction queue, including: Sequentially taking out non-transaction operation requests from the non-transaction queue and executing them to obtain non-transaction result responses; Put the non-transaction result response into a response return queue; When the non-transaction result response is taken out from the response reporting queue, the non-transaction result response is returned to the user end.

10. The method according to claim 1, characterized in that The transaction operating system further includes a transaction platform, and the non-transaction operation request includes a market operation request; Before sequentially taking out non-transaction operation requests from the non-transaction queue and executing them, the method further includes: Receiving updated market information sent by the trading platform; Constructing the market operation request for the updated market information, and placing the market operation request into the non-transaction queue; The triggering sequentially extracts and executes non-transaction operation requests from the non-transaction queue, including: Triggering to retrieve the market operation request from the non-transaction queue and execute it, and updating the market information in the transaction intermediary platform based on the updated market information.

11. A transaction operating system, characterized in that: Including user end, transaction intermediary platform and transaction platform; The user terminal is used to send a transaction operation request or a non-transaction operation request to the transaction intermediary platform, and receive a transaction return response or a non-transaction result response returned by the transaction intermediary platform; The transaction intermediary platform is configured to obtain a transaction queue and a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; trigger sequentially retrieving and executing transaction operation requests from the transaction queue; and trigger sequentially retrieving and executing non-transaction operation requests from the non-transaction queue when the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, wherein the execution priority of the non-transaction operation request is lower than that of the transaction operation request, and the basis for determining the preset time condition includes: determining whether a current timestamp of the completion of execution of the first preset number of transaction operation requests is within a dynamic time window defined by an update market information message returned by the transaction platform; and when the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, jump to sequentially retrieving and executing transaction operation requests from the transaction queue. The trading platform is configured to receive the transaction operation information sent by the transaction intermediary platform and return a transaction result report; The trading platform is also used to send updated market information to the trading intermediary platform.

12. The transaction operating system according to claim 11, characterized in that: The transaction intermediary platform includes a request scheduling module, a request execution module, and an uplink and downlink module; The request scheduling module is configured to receive the operation request sent by the user terminal and place the request in a transaction queue or a non-transaction queue, wherein the execution priority of the non-transaction queue is lower than that of the transaction queue; The request execution module is configured to sequentially retrieve and execute transaction operation requests from the transaction queue; when the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, trigger the sequential retrieval and execution of non-transaction operation requests from the non-transaction queue, wherein the execution priority of the non-transaction operation requests is lower than that of the transaction operation requests; and when the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, jump to sequentially retrieval and execution of transaction operation requests from the transaction queue. The uplink and downlink module is used to send the transaction operation message to the trading platform and receive the transaction result report returned by the trading platform; The uplink and downlink modules are further configured to receive updated market information sent by the trading platform.

13. A computing device, characterized in that include: memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer program / instructions are executed by the processor, the steps of the operation request execution method according to any one of claims 1 to 10 are implemented.

14. A computer-readable storage medium, characterized in that It stores a computer program / instruction, which, when executed by a processor, implements the steps of the operation request execution method according to any one of claims 1 to 10.

15. A computer program product, characterized in that The method comprises a computer program / instruction, which, when executed by a processor, implements the steps of the operation request execution method according to any one of claims 1 to 10.

Images