Operation request execution method, transaction operation system and computing device

Abstract

The embodiment of the invention provides an operation request execution method, a transaction operation system and computing equipment, the operation request execution method is applied to a transaction intermediary platform in the transaction operation system, the method comprises the steps that a transaction queue and a non-transaction queue are acquired, and the execution priority of the non-transaction queue is lower than that of the transaction queue; triggering to sequentially take out the transaction operation requests from the transaction queue and executing the transaction operation requests; under the condition that the number of the executed transaction operation requests reaches a first preset number and a preset time condition is met, triggering to sequentially take out non-transaction operation requests from a non-transaction queue and execute the non-transaction operation requests, the execution priority of the non-transaction operation requests being lower than that of the transaction operation requests; and when the number of the executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, skipping to sequentially take out the transaction operation requests from the transaction queue and executing the transaction operation requests. The collaborative optimization execution between the transaction operation request and the non-transaction operation request is realized.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of financial transaction technology, and in particular to a method for executing an operation request, a transaction operating system, and a computing device. Background Art

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

[0003] Currently, trading systems typically use a single-threaded or fixed-queue model to process all operation requests. These systems complete tasks such as order placement, report processing, and query requests by executing them sequentially in the order they are received. Some approaches attempt to introduce multi-queue scheduling mechanisms, allocating processing resources through static partitioning strategies.

[0004] However, the aforementioned technical solution relies solely on pre-set priority rules to control transaction task switching, lacking dynamic scheduling logic for requests of varying priorities. This makes it difficult to dynamically prioritize higher-priority requests, resulting in high-priority requests being blocked and delayed by lower-priority requests. This, in turn, makes it impossible to ensure the timely execution of critical transactions, impacting the efficiency and stability of the financial transaction system's operations. Therefore, a more rational and efficient method for executing operation requests is urgently needed. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a method for executing an operation request. One or more embodiments of this specification also relate to a transaction operating system, a computing device, a computer-readable storage medium, and a computer program product to address technical deficiencies in the prior art.

[0006] One aspect of an embodiment of the present specification provides an operation request execution method, which is applied to a transaction intermediary platform in a transaction operating system, the method comprising: obtaining 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 sequentially retrieving and executing 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, triggering sequentially retrieving and executing 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; when the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, jumping to sequentially retrieving and executing transaction operation requests from the transaction queue.

[0007] By storing transaction operation requests and non-transaction operation requests with different execution priorities in isolated transaction queues and non-transaction queues respectively, and combining a dynamic switching mechanism with dual verification of preset quantity thresholds and preset time conditions, high-priority transaction operation requests are given priority when the transaction queue is not empty. When the number of executed transaction operation requests 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 returns to the transaction queue when the number of executed non-transaction operation requests reaches a second preset number, forming a cyclical dynamic scheduling mode, ensuring the priority execution of transaction operation requests and the execution guarantee of non-transaction operation requests, achieving a 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 responsiveness of the transaction operating system, reducing context switching overhead, and achieving coordinated and optimized execution of transaction operation requests and non-transaction operation requests under a single-threaded architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 It is a schematic diagram of an operation request execution framework in the prior art; Figure 2 This is a flowchart of a method for executing an operation request provided by one embodiment of this specification; Figure 3 This is a schematic diagram of a framework of a transaction operating system provided by one embodiment of this specification; Figure 4 This is a schematic diagram of a processing framework of a method for executing an operation request provided by an embodiment of this specification; Figure 5 This is a flowchart of a processing process of an operation request execution method provided by an embodiment of this specification; Figure 6 This is a schematic diagram of the structure of a transaction operating system provided by one embodiment of this specification; Figure 7 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0009] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0010] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0011] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0012] 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 used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0013] First, the terms involved in one or more embodiments of this specification are explained.

[0014] First In, First Out (FIFO) is a queue processing mechanism that ensures that tasks or data are processed in the order they are received. First in, first out. It is often used to ensure the orderliness and timing consistency of transaction operation requests.

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

[0016] The User Datagram Protocol (UDP) interface is a communication interface based on the UDP protocol. It can send data packets without establishing a connection and has low latency. It is suitable for transmitting transaction operation requests with extremely high real-time requirements in high-frequency trading scenarios.

[0017] A seat is a unique legal identity assigned by a trading platform to a trading intermediary platform. It is used to verify the legitimacy of trading operation requests and ensure the execution authority and compliance of trading instructions in the exchange system.

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

[0019] Currently, trading systems typically use a single-threaded or fixed-queue model to process all operation requests. These systems complete tasks such as order placement, report processing, and query requests by executing them sequentially in the order they are received. Some approaches attempt to introduce multi-queue scheduling mechanisms, allocating processing resources through static partitioning strategies.

[0020] See also Figure 1 , Figure 1 A schematic diagram of an operation request execution framework in the prior art is shown. Figure 1 As shown: The user end first establishes a handshake connection with the main thread in the core thread of the trading system, obtains the port, and then disconnects the handshake connection; uses the port returned by the handshake connection to establish a TCP connection with the main thread and log in; the main thread returns a login response, including a token field for identity authentication; reuses the token field returned by the login to place and cancel orders to the UDO order thread; verifies capital and positions through the API thread of the quotation exchange in the trading system quotation, and submits the order to the quotation, where the API thread of the quotation exchange supports multiple seats; receives the order work thread returned by the exchange and inserts it into the return queue; updates funds and positions based on the return, and pushes the return.

[0021] Among them, in the main thread, the handshake connection function (binding port A), connection establishment and disconnection (epoll), port allocation according to account configuration permissions (different threads bind different ports), and management function processing.

[0022] In the User Datagram Protocol (UDP) message line, While (1)----bind ports B1 and B2 {1. Scan naked agreement orders and cancellation requests (10 consecutive scans each time) 2. Scan the report queue to process the report information 3. Scan the TCP connection queue and process TCP requests (except for placing and canceling orders and other function numbers) 4. Process TCP connection and disconnection requests and maintain the TCP connection queue (one thread supports 16 connections)}.

[0023] In the TCP report thread, While (1)----bind ports C1 and C2 {1. Scan the TCP connection queue and process TCP requests (order placement, order cancellation, query, etc.) 2. Scan the report queue to process the report information 3. Process TCP connection and disconnection requests and maintain the TCP connection queue (one thread supports 16 connections) However, in the above technical solution, since it only relies on preset priority division rules to control transaction task switching, it lacks dynamic scheduling logic for requests of different priorities, making it difficult to dynamically prioritize the execution of operation requests with higher priorities. Non-transaction operation requests such as login response, capital verification, and position verification are not distinguished from order transaction operation requests, resulting in high-priority operation requests being blocked and delayed by low-priority operation requests, which in turn makes it impossible to take into account the timeliness of the execution of key transaction business, affecting the execution efficiency and stability of operation requests of the financial transaction system.

[0024] In view of this, in this specification, an operation request execution method is provided. This specification also involves a transaction operating 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.

[0025] See also Figure 2 , Figure 2 A flowchart of an operation request execution method provided according to an embodiment of the present specification is shown. The operation request execution method is applied to a transaction intermediary platform in a transaction operating system and specifically includes the following steps.

[0026] Step 202: 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.

[0027] The operation request execution method provided in the embodiments of this specification can be applied to a transaction operating system in the financial field. The transaction subject matter or objects in the transaction operating system can be stocks, bonds, futures, foreign exchange, etc., as well as physical goods or services, or digital rights such as digital copyrights and digital artworks. This embodiment of this specification does not specifically limit this.

[0028] The trading operating system is an integrated processing platform used to coordinate the reception, classification, execution and response of various operation requests in the trading system under various trading scenarios. Figure 3 , Figure 3A schematic diagram of a trading operating system according to an embodiment of the present specification is shown. Figure 3 shown.

[0029] The trading operation system may include a trading intermediary platform and, optionally, a user terminal and a trading platform. The user terminal may be responsible for initiating trading operation requests and / or non-trading operation requests to the trading intermediary platform and receiving trading response responses and / or non-trading result responses returned by the trading intermediary platform. The trading intermediary platform is configured to receive trading operation requests and / or trading operation requests sent by the user terminal, determine trading operation information, and send it to the trading platform. Furthermore, the trading intermediary platform receives trading result responses and / or market update messages automatically sent by the trading platform and sends trading response responses and / or non-trading result responses to the user terminal. The trading platform is responsible for receiving trading operation information sent by the trading intermediary platform and returning trading result responses, while automatically sending market update messages to the trading intermediary platform at preset intervals. For example, when a user terminal submits a trading operation request for an order, the trading operation system receives the trading operation request through the trading intermediary platform, determines the corresponding trading operation information, sends it to the trading platform, receives the trading result response for the actual trading operation, generates a trading response response, and sends it to the user terminal.

[0030] The transaction intermediary platform is the core scheduling module of the trading operating system. It is responsible for accessing transaction and non-transaction queues, extracting and executing operation requests from the queues according to pre-set rules. Alternatively, the transaction intermediary platform can receive operation requests and place them into the corresponding queue based on the request type. The transaction intermediary platform processes high-priority transaction operation requests in the transaction queue using a separate thread, while periodically switching to handle low-priority requests in the non-transaction queue to ensure the timeliness of critical business operations.

[0031] The trade queue is a dedicated queue within the trading intermediary platform used to store high-priority trade operation requests. It ensures the real-time and stable execution of trade operation requests (such as order placement and order cancellation). The trade queue has a higher execution priority than non-trading queues. The trade queue uses an independent thread to exclusively process trade operations, ensuring that trade operation requests are executed sequentially within the trade queue without interference from other lower-priority tasks. For example, if a user submits a high-priority "order placement" trade operation request, the trading intermediary platform will place it in the trade queue and prioritize its processing within the current scheduling cycle.

[0032] The non-trading queue is a dedicated queue within the trading intermediary platform used to store low-priority non-trading requests. It ensures data integrity and system responsiveness for non-trading requests (such as inquiries, logins, and market updates). The non-trading queue has a lower execution priority than the trading queue. Execution of the non-trading queue is triggered only after the trading queue reaches a preset threshold. A periodic scheduling mechanism ensures that non-trading tasks receive an opportunity to execute. For example, after a trading queue has executed 100 trading requests in a loop, the trading intermediary platform will switch to the non-trading queue and process non-trading requests, such as user-submitted position information queries.

[0033] Specifically, the transaction queue and the non-transaction queue can be directly obtained from the local storage medium of the transaction operating system, or from the server cache of the transaction operating system, or from a cloud server through a cloud service provider, etc. This embodiment of the specification does not make specific limitations on this.

[0034] Optionally, for transaction queues and non-transaction queues, operation requests sent by users can be received and placed in corresponding queues, so that corresponding operation requests can be sequentially retrieved from the transaction queue or non-transaction queue in subsequent executions.

[0035] Optionally, the classification of operation requests can be performed according to preset classification rules, such as classification based on keywords of the operation requests, or classification based on the operation objects of the operation requests; or classification can be performed directly based on the operation classification identifier carried in the operation request, such as a function number.

[0036] Optionally, when placing an operation request into a transaction queue or a non-transaction queue, the source of the operation request needs to be considered and thread positioning needs to be performed to achieve separate execution based on different threads, thereby ensuring the independence between transaction businesses and the continuity within each thread.

[0037] In this step, by obtaining the transaction queue and non-transaction queue, a data basis is provided for the subsequent execution of transaction operation requests and non-transaction operation requests. By obtaining the sub-queues, physical isolation of operation requests of different priorities is achieved.

[0038] Step 204: triggering the sequential retrieval of transaction operation requests from the transaction queue and executing them.

[0039] Trading operation requests are high-priority instructions sent by the user end within the trading operating system, requiring execution through the trading intermediary platform. Trading operation requests are prioritized over non-trading operation requests. Trading operation requests require high real-time execution and stability. Specifically, trading operation requests typically include order submissions and order cancellations, which typically require upstream and downstream quote communication with the trading platform. Trading operation requests must be executed sequentially within the trading queue to ensure critical business timeliness.

[0040] 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 is dispatched by the transaction intermediary platform to the transaction queue for execution.

[0041] Specifically, the conditions that trigger the sequential removal of transaction operation requests from the transaction queue may include a reset of the transaction queue's status after initialization is complete or the previous scheduling cycle ends. Specifically, once the transaction intermediary platform has completed the acquisition of the transaction queue and non-transaction queue and confirmed the existence of pending transaction operation requests in the transaction queue, it can exclusively process the transaction queue, sequentially removing and executing transaction operation requests from the transaction queue.

[0042] Specifically, trade operation requests in the transaction queue are removed sequentially according to the first-in, first-out (FIFO) principle, ensuring that trade operation requests can be executed in the order they were received. The transaction intermediary platform controls the execution of trade operation requests in the transaction queue through an independent thread. It continuously polls the transaction queue status and removes requests one by one when the queue is not empty, ensuring priority execution of trade operation requests in the transaction queue.

[0043] Optionally, the continuous polling of the transaction queue may end when a preset number of polls are completed, or may end when a preset number of transaction operation requests are executed.

[0044] Specifically, the execution of a transaction operation request can be handled by the transaction intermediary platform. This processing can include verification, such as verifying the legitimacy of the request and transaction eligibility, as well as updating transaction intermediary platform information. After the transaction intermediary platform completes processing the transaction operation request, it can obtain transaction operation information based on the transaction operation request. Transaction operation information is operational information sent to the transaction platform and can include actual transaction tasks or transaction objectives. This transaction operation information can be transmitted through the connection between the transaction intermediary platform and the transaction platform.

[0045] Specifically, trading platforms typically have a pre-set API interface for communication and seat verification with the trading intermediary platform. The trading intermediary platform sends trading operation information to the trading platform through the trading platform's interface and receives a return transaction response, completing the execution of the trading operation request.

[0046] For example, in a financial transaction scenario, for order request A taken out from the transaction queue, the transaction intermediary platform first verifies the user's funds and positions to confirm the transaction qualifications. If the verification is passed, the transaction operation information corresponding to order request A is submitted to the transaction platform through the preset interface, and waits for the execution result returned by the transaction platform.

[0047] In this step, by sequentially retrieving and executing transaction operation requests from the transaction queue, the transaction intermediary platform can achieve exclusive execution of the transaction queue, ensuring exclusive processing of high-priority transaction operation requests and avoiding interference from low-priority non-transaction operation requests, thereby significantly reducing the delay of key transaction business.

[0048] Step 206: When the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, triggering sequential retrieval of non-transaction operation requests from the non-transaction queue and executing them, wherein the execution priority of the non-transaction operation requests is lower than that of the transaction operation requests.

[0049] The first preset number is a dynamic switching threshold set in the trading operating system to control the execution frequency of trading operation requests. The value of the first preset number can be determined by the system configuration file or runtime parameters and is used to measure the upper limit of processing high-priority tasks in the trading queue. Specifically, the setting of the first preset number should comprehensively consider the trading system's throughput, latency tolerance, and resource allocation strategy to ensure that the execution window for non-trading operation requests is reserved while ensuring the real-time execution of high-priority trading operations. For example, if the first preset number is set to 100, after processing 100 consecutive trading operation requests (such as order submissions and order cancellations), the trading intermediary platform will exit the exclusive processing thread, actively switch from executing in the trading queue to the non-trading queue, and execute low-priority non-trading operation requests.

[0050] Preset time conditions are dynamic time-determination rules used in the trading system to control the switch from the trading queue to the non-trading queue. Preset time conditions are determined based on the interval (also known as time slice) between market updates returned by the trading platform, ensuring that the waiting time for market updates is not too long, thereby affecting the basic responsiveness of the trading system.

[0051] Optionally, the determination of the preset time condition may be based on the correlation between the timestamp and the time window. Specifically, the determination of the preset time condition may include determining whether the current timestamp of the completion of the first preset number of trading operation requests falls within the dynamic time window defined by the market update message returned by the trading platform. If so, the trading operation requests are sequentially retrieved and executed from the trading queue; if not, the non-trading operation requests are sequentially retrieved and executed from the non-trading queue. The determination of the preset time condition may also include determining whether the elapsed execution time of the trading queue meets a preset time interval threshold calculated based on the current timestamp.

[0052] For example, in a financial transaction scenario, in the time slice of the updated market information returned by the trading platform, when the number of transaction operation requests reaches a first preset number, a comparison can be further performed based on the current timestamp and the timestamp of the last updated market information message sent by the trading platform. If the current timestamp exceeds the dynamic time window determined by the timestamp of the updated market information, the execution process of the non-transaction queue is triggered; otherwise, if the current timestamp is still within the time window, the transaction queue will continue to be processed with priority.

[0053] Non-trading operation requests are low-priority operations initiated by the user in the trading operating system and scheduled for execution by the trading intermediary platform. They are executed at a lower priority than trading operation requests. They place higher demands on data integrity and system responsiveness, but lower on real-time performance. Specifically, non-trading operation requests typically include queries (such as account information and position inquiries), login verification, market updates, and other operations that do not directly change trading status. These requests typically do not require the involvement of the trading platform and can be executed directly through the trading intermediary platform. Non-trading operation requests are executed sequentially within the non-trading queue to ensure overall system responsiveness.

[0054] Specifically, the retrieval and execution of non-transactional operation requests must be triggered after a preset threshold number of transactional operation requests have been completed in the transaction queue, and a periodic scheduling mechanism is used to ensure that low-priority tasks are given execution opportunities, thereby avoiding interference with high-priority transactional businesses while maintaining the functionality and availability of the system.

[0055] Specifically, the execution of non-transaction operation requests can be processed by the transaction intermediary platform, and the processing may include querying corresponding information, login verification, etc., such as verifying whether the login of the user account is abnormal or querying the user's transaction status.

[0056] Optionally, after the non-transaction operation request is executed, a non-transaction result response can be obtained to be fed back to the user end as a result. Specifically, the non-transaction result response can be returned to the user end by directly calling the corresponding interface through the protocol connection relationship between the transaction intermediary platform and the user end; the non-transaction result response can also be placed in a response return queue and returned to the user end based on the response return queue.

[0057] Optionally, non-transactional operation requests may include those that do not require a non-transactional response, such as market information operation requests. Specifically, the trading platform may proactively send current transaction information to the trading intermediary platform at preset intervals. These information need not be sent directly to the user end; instead, it only needs to be maintained and updated within the trading intermediary platform. Users who wish to obtain these information can then submit corresponding query requests. Therefore, to execute the market information operation request, the trading intermediary platform simply updates the market information maintained within the trading intermediary platform based on the corresponding updated market information, without generating a non-transactional response.

[0058] In this step, by triggering the execution of non-transaction operation requests in the non-transaction queue when the number of transaction operation requests reaches a first preset number and meets the preset time condition, the transaction intermediary platform can achieve flexible scheduling between transaction tasks and non-transaction tasks by combining further judgment with the preset time condition while ensuring the real-time performance of high-priority tasks. While ensuring the real-time performance of key transaction services, it avoids waste of system resources or response delays caused by non-transaction tasks occupying resources, periodically releases system resources to process low-priority non-transaction operation requests, and controls the task switching frequency through a dual judgment mechanism of a preset number threshold and a preset time condition. It avoids waste of resources caused by long-term monopoly of the transaction queue, and prevents non-transaction tasks from affecting the overall response capability of the system due to long-term non-execution, and realizes the coordinated optimization execution of transaction and non-transaction operation requests under a single-threaded architecture.

[0059] Step 208: When the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty, jump to sequentially retrieve transaction operation requests from the transaction queue and execute them.

[0060] The second preset number is a dynamic switching threshold set in the trading operating system to control the execution frequency of non-trading operation requests. The value of the first preset number can be determined by the system configuration file or runtime parameters, and is used to measure the upper limit for processing low-priority tasks in the non-trading queue. Specifically, the second preset number should be set based on the data integrity requirements of non-trading tasks, the system resource allocation strategy, and the urgency of pending tasks in the trading queue. This ensures that resources are promptly released to process high-priority trading requests while ensuring the execution of non-trading operation requests.

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

[0062] Optionally, in the non-transaction queue, non-transaction operation requests may be stored in the form of a buffer, and a single cache block may store multiple non-transaction operation requests. Therefore, the second preset number may also be determined based on the number of non-transaction operation requests stored in the cache block.

[0063] After the second preset number of non-transaction operation requests have been executed, the transaction queue may be further polled to see if it is empty. If the transaction queue is not empty, the transaction queue may be jumped to, that is, transaction operation requests are sequentially retrieved from the transaction queue and executed.

[0064] Optionally, when the transaction queue is empty, the step of sequentially retrieving and executing non-transaction operation requests from the non-transaction queue can be triggered again, and when a second preset number of non-transaction operation requests are executed again, the transaction queue is polled to see if it is empty.

[0065] In the embodiments of the present specification, transaction operation requests and non-transaction operation requests with different execution priorities are stored in mutually isolated transaction queues and non-transaction queues, respectively. In combination with a dynamic switching mechanism with dual verification of a preset number threshold and a preset time condition, high-priority transaction operation requests are processed preferentially when the transaction queue is not empty. When the number of executed transaction operation requests reaches a first preset number and a preset time condition is met, the system actively switches to the non-transaction queue to process low-priority non-transaction operation requests. When the number of executed non-transaction operation requests reaches a second preset number, the system immediately returns to the transaction queue. This forms a cyclic dynamic scheduling mode, ensures the priority execution of transaction operation requests and the guaranteed execution of non-transaction operation requests, achieves a dynamic balance between resource allocation and task scheduling, takes into account the overall efficiency of the transaction system and the timeliness requirements of key business operations, maintains the overall responsiveness of the transaction operating system, reduces context switching overhead, and achieves coordinated and optimized execution of transaction operation requests and non-transaction operation requests under a single-threaded architecture.

[0066] In an optional embodiment of the present specification, when the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, triggering the sequential retrieval of non-transaction operation requests from a non-transaction queue and execution thereof, includes: when the number of executed transaction operation requests reaches the first preset number, obtaining a current timestamp; determining whether the current timestamp is within a time window; if not, triggering the sequential retrieval of non-transaction operation requests from the non-transaction queue and execution thereof.

[0067] The current timestamp is a system timestamp captured by the trading operating system at a specific moment. It is used to measure the execution timing of operation requests and trigger the scheduling logic. Because operation requests execute very quickly, timestamps can typically be recorded with millisecond or microsecond accuracy. The current timestamp is the timestamp after a first preset number of trading operation requests have completed. Specifically, when the number of trading operation requests reaches the first preset number, the trading intermediary platform will obtain the current timestamp and compare it with the start and end times of the time window to determine whether to trigger the execution process of the non-trading queue.

[0068] A time window is a dynamic time period set within the trading operating system to control the timing of non-trading operation requests. The start and end times of the time window can be determined by the timestamp of the market update message returned by the trading platform, ensuring that the waiting time for the updated market message is not excessive and thus affects the basic responsiveness of the trading operating system. The length of the time window can be flexibly and dynamically set based on different usage scenarios. Optionally, it can be determined based on the actual time interval between market update messages returned by the trading platform, or based on the trading intermediary platform's performance in executing operation requests. This specification does not specifically limit this.

[0069] 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 market update message returned by the trading platform when the trading operation request is executed; the second time window can be determined based on the timestamp of the last market update message returned by the trading platform after a first preset number of trading operation requests are executed.

[0070] For example, in a financial transaction scenario, when a preset number of 100 order placement and / or order cancellation transaction operation requests are executed continuously, the current timestamp T=240ms is obtained and compared with the preset time window [0, 200ms] to determine whether the current timestamp falls within the time window; T=240ms 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, thereby triggering the sequential retrieval and execution of non-transaction operation requests from the non-transaction queue.

[0071] In the embodiments of this specification, by introducing a dynamic judgment mechanism based on a time window, the transaction intermediary platform can prioritize the execution of high-priority transaction operation requests, avoiding transaction delays caused by non-transaction tasks occupying resources. At the same time, the task switching logic is controlled by the correlation between the timestamp and the time window, ensuring that non-transaction operation requests have the opportunity to be executed during non-critical periods. The dynamic time window adjustment can adapt to the resource allocation requirements in different transaction scenarios, and realize the balance optimization between transaction operation requests and non-transaction operation requests under the single-threaded architecture.

[0072] In an optional embodiment of the present specification, the trading operating system also 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, the first timestamp is the timestamp of the first updated market message returned by the trading platform, and the second time window is determined according to a second timestamp, the second timestamp is the timestamp of the last updated market message returned by the trading platform; judging whether the current timestamp is within the time window, and if not, triggering the sequential retrieval of non-trading operation requests from the non-trading queue and executing them, includes: judging whether the current timestamp is within the first time window, and if not, triggering the sequential retrieval of non-trading operation requests from the non-trading queue and executing them; and / or judging whether the current timestamp is within the second time window, and if not, triggering the sequential retrieval of non-trading operation requests from the non-trading queue and executing them.

[0073] A trading platform is a component of a trading system responsible for executing trading instructions and returning transaction results. This includes, for example, stock exchanges, futures exchanges, and foreign exchange trading platforms in financial trading scenarios, as well as e-commerce trading platforms and energy resource trading platforms. Trading platforms communicate with intermediary trading platforms via pre-defined protocol interfaces to communicate upstream and downstream quotes. Specifically, the trading platform receives trading operation information from the intermediary platform, completes the actual transaction, and returns transaction results. For example, in a financial trading scenario, after the intermediary platform sends a stock buy order request, it submits the request to the exchange through the exchange's API interface and returns transaction results to the intermediary platform upon completion.

[0074] The first time window is a dynamic time period within the trading operating system that controls the execution timing of non-trading operation requests. The start time of the first time window can be determined by the timestamp of the first market update message returned by the trading platform. Furthermore, the length of the first time window can be dynamically adjusted based on the frequency with which the trading platform sends market update messages. Specifically, the first time window can be used to protect the execution of non-trading operation requests in the non-trading queue. For example, in a financial trading scenario, when the trading platform first sends a stock market update message, the trading intermediary platform will use the timestamp T1 of the message as the starting point of the first time window. Based on T1 and a preset window length (e.g., 250ms), the trading queue will be executed if the current timestamp is within the first time window. If the current timestamp is outside the first time window, the non-trading queue will be switched to execute.

[0075] The second time window is also a dynamic time period within the trading operating system that controls the execution timing of non-trading operation requests. The start time of the second time window is determined by the timestamp of the last market update message returned by the trading platform. The length of the second time window can also be dynamically adjusted based on the frequency of market update message transmission by the trading platform. Specifically, the second time window can be used to prioritize the processing of high-priority trading operation requests during the market update message transmission period. For example, in a financial trading scenario, when executing a trading operation request, the trading platform sends multiple market update messages concurrently. The trading intermediary platform will use the timestamp T2 of the last market update message as the start point of the second time window. Based on T2 and a preset window length (e.g., 150ms), the trading queue will be executed. If the current timestamp is within the second time window, the non-trading queue will be switched to execution.

[0076] The first timestamp is the system timestamp of the first market update message returned by the trading platform. It is used to identify the starting time of the waiting period for the first market update message. The first timestamp is the core basis for the trading intermediary platform to determine whether to enter the first time window.

[0077] Update market messages are data packets sent by the trading platform to update market information on the intermediary trading platform. These messages are typically sent at preset intervals (also known as time slices), such as 500ms. These intervals can be set based on the trading platform's real-time market updates. Update market messages typically include key fields such as the underlying asset code, latest price, and trading volume.

[0078] The first market update message is the first market data packet sent by the trading platform during the execution period of a specific trading operation request. It can be used to trigger the trading operating system's first time window timing and initialize the monitoring logic for market update messages. For example, in a financial trading scenario, when the real-time quote of Stock A changes for the first time, the trading platform will generate and send an update message, which may include the latest transaction price of Stock A of 100.5 yuan and the trading volume of 1000 lots. The trading intermediary platform can start the first time window timing based on the first timestamp of the first received update message.

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

[0080] The last updated market message is the last market data packet sent by the trading platform during a specific trading period, and can be used to trigger the second time window timing of the trading operating system.

[0081] Specifically, the first time window is the time window starting from the first timestamp and can be understood as the waiting time for the first updated market message. The second time window is the time window starting from the second timestamp and can be understood as the waiting time for the last updated market message. Therefore, if there is only one updated market message, the first time window and the second time window are the same.

[0082] Specifically, once the first and second time windows are determined, a judgment can be made based on the current timestamp. The judgment criteria for the first and second time windows are independent of each other. That is, if the current timestamp does not fall within either time window, both trigger the sequential retrieval of non-transaction operation requests from the non-transaction queue and their execution.

[0083] Specifically, in the process of executing the first preset number of transaction operation requests, the transaction intermediary platform will simultaneously send multiple update market information messages to the transaction intermediary platform. For example, the update market information sent by the transaction platform is generally sent in slices of 500ms. At the same time, the transaction intermediary platform will determine the first timestamp T1 based on the reception time of the first update market information message, and update the second timestamp T2 after each update market information message is received, until the first preset number of transaction operation requests are completed, and the reception time of the last update market information message received in the same slice is determined as the second timestamp T2; based on the preset time length, the first time window (for example, if the preset time length of the first time window is 250ms, then the first time window is [T1, T1+250ms]) and the second time window (for example, if the preset time length of the second time window is 150ms, then the second time window is [T2, T2+150ms]) are determined respectively; based on whether the current timestamp is within the first time window or the second time window, it is determined whether to trigger the withdrawal and execution of the non-transaction task.

[0084] Optionally, if the current timestamp is within the first time window and / or the second time window, indicating that the first updated market message and / or the last updated market message can still be waited for, then the process returns to the step of sequentially retrieving and executing transaction operation requests from the transaction queue until the current timestamp is no longer within the first time window and / or the second time window, switching to execution in the non-transaction queue.

[0085] For example, in a financial transaction scenario, in the process of completing the execution of a first preset number of transaction operation requests, the first timestamp T1 of the first updated market message received by the transaction intermediary platform is 09:00:00.000, and the second timestamp T2 of the last updated market message is 09:00:00.150; if the length of the first time window is 250ms and the length of the second time window is 150ms, then the first time window can be determined to be [09:00:00.000, 09:00:00.250] and the second time window can be determined to be [09:00:00.150, 09:00:00.300]; the current timestamp T after the transaction intermediary platform completes the first preset number of transaction operation requests is 09:00:00.260, which is within the second time window, but has exceeded the first time window, thus triggering the sequential retrieval and execution of non-transaction operation requests from the non-transaction queue.

[0086] In the embodiments of this specification, by further refining the time window into a first time window and a second time window based on the arrival time of each updated market message, the transaction intermediary platform can ensure that the processing of the updated market message will not exceed the maximum waiting time, while giving priority to the execution of high-priority transaction operation requests, thereby avoiding transaction delays caused by non-transaction tasks occupying resources; through the independent judgment mechanism of the dual time windows, a balance optimization between transaction operation requests and non-transaction operation requests is achieved under a single-threaded architecture.

[0087] In an optional embodiment of the present specification, the transaction operating system further includes a user terminal; before obtaining the transaction queue and the non-transaction queue, it further includes: receiving a target operation request sent by the user terminal; and placing the target operation request into the transaction queue and / or the non-transaction queue.

[0088] The user end is a terminal device or client in a trading operating system that initiates operation requests and receives responses. This can be client software, mobile applications, or web interfaces in financial trading scenarios, or terminal devices in fields such as e-commerce and energy resources. The user end can send trading operation requests (such as placing and canceling orders) or non-trading operation requests (such as query requests and login requests) to the trading intermediary platform and receive transaction feedback or non-trading result responses from the trading intermediary platform.

[0089] A target operation request is a specific instruction sent by the user to the trading intermediary platform. The type of target operation request can be determined by the operation content, such as a high-priority trading operation request (such as placing or canceling an order) or a low-priority non-trading operation request (such as account query or login verification).

[0090] Specifically, a target operation request can carry an operation classification identifier (such as a function number) or an operation object (such as an underlying asset code). The trading intermediary platform can then classify and process the target operation request based on the operation classification. For example, in a financial trading scenario, a user-submitted target operation request to "buy 100 lots of stock A" could be classified as a trading operation request, while a user-submitted target operation request to "query current holdings" could be classified as a non-trading operation request.

[0091] Optionally, the transaction intermediary platform and the user terminal may communicate via a protocol interface. Specifically, the user terminal may send an operation request to the transaction intermediary platform via the protocol interface, and the transaction intermediary platform may send a transaction return response and / or a non-transaction result response to the user terminal via the protocol interface.

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

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

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

[0095] In the embodiments of this specification, by receiving target operation requests sent by the user terminal and classifying them into transaction queues or non-transaction queues based on the type of operation requests, accurate classification of operation requests is achieved. By physically isolating the transaction queues and non-transaction queues, the transaction intermediary platform can realize the division of operation requests of different priorities in the process of receiving operation requests, ensuring that the real-time and stability requirements of transaction operation requests are met first, while ensuring the data integrity and system responsiveness of non-transaction operation requests, thereby realizing efficient collaborative execution of transaction operation requests and non-transaction operation requests under a single-threaded architecture.

[0096] 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 transmission control protocol interface; placing the target operation request into a transaction queue and / or a non-transaction queue, including: 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; if the target operation request is a transaction operation request, placing the target operation request into the transaction queue; if the target operation request is a non-transaction operation request, placing the target operation request into the non-transaction queue.

[0097] The Transmission Control Protocol interface is a communication protocol interface used in a trading operating system to ensure reliable data transmission. The Transmission Control Protocol interface implements 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 a three-way handshake connection, bidirectional communication can be achieved, and the reliability of the connection and the sequence of data transmission can be guaranteed. Therefore, the Transmission Protocol interface can be used in scenarios with high requirements for data integrity. For example, in a financial transaction scenario, when a user submits a transaction operation request for "buy 100 lots of stocks" through the TCP interface, the transaction intermediary platform will verify the legitimacy of the protocol connection request and ensure the smooth establishment of the communication connection based on the confirmation mechanism of the TCP protocol, thereby completing the complete reception of the operation request and avoiding data loss or disorder.

[0098] The operation classification identifier is used in the trading operating system to distinguish between transactional and non-transactional operation requests. The operation classification identifier can include a function number, operation object, or other predefined fields embedded in the target operation request.

[0099] Specifically, the operation classification identifier defines the priority and processing logic of the operation request through preset rules. For example, "order submission" and "order cancellation" type operation requests are identified as transaction operation requests, and "query" and "login" type requests are identified as non-transaction operation requests.

[0100] Once the target operation request type is determined, the target operation request can be placed in the corresponding queue. Specifically, because the transmission control protocol interface is bidirectional, the transaction intermediary platform can return transaction response responses for transaction operation results and / or non-transaction response responses for non-transaction operation results to the user terminal via the transmission control protocol interface.

[0101] 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 method further includes: performing thread positioning for the target operation.

[0102] Specifically, a thread is the smallest unit of program execution in an operating system. It is an independent execution flow within a process and can execute multiple tasks concurrently. Threads can share resources (such as memory and file handles) with their respective processes, but have independent program counters, register sets, and stacks. Due to their lightweight nature, threads offer high scheduling efficiency and are suitable for scenarios requiring high concurrency or real-time response. Thread localization is the process of mapping specific operation requests to appropriate threads, aiming to optimize resource allocation and task execution efficiency. In a trading operating system, thread localization can determine which thread handles received operation requests based on pre-defined localization rules or policies (such as priority and client identity). For example, trading operation requests can be localized to threads in the high-priority thread pool, while non-trading operation requests can be assigned to low-priority threads. Targeted operation requests sent by each client via the Transmission Control Protocol interface can also be localized to independent threads based on client identity to prevent interference between clients. Thread localization ensures the real-time performance of critical tasks and overall system stability by rationally allocating thread resources.

[0103] For example, in a financial transaction scenario, the operation request for "Cancel order of stock B" submitted by the user terminal carries the function number "T003". The transaction intermediary platform identifies it as a transaction operation request and puts it into the transaction queue based on the correspondence between the preset function number and the operation category; the "Query account balance" request submitted by the user terminal carries the function number "Q004". The transaction intermediary platform identifies it as a non-transaction operation request and puts it into the non-transaction queue based on the correspondence between the preset function number and the operation category.

[0104] In the embodiments of this specification, by receiving target operation requests sent by a user terminal through a transmission control protocol interface and implementing classification logic based on an operation classification identifier, accurate classification of the target operation requests is achieved, thereby ensuring the integrity and sequential execution of transaction operation requests, as well as accurate classification and resource allocation of non-transaction operation requests, thereby achieving efficient coordinated execution of transaction operation requests and non-transaction operation requests under a single-threaded architecture.

[0105] 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; placing the target operation request into a transaction queue and / or a non-transaction queue includes: placing the target operation request into a transaction queue.

[0106] The User Datagram Protocol (UDP) interface is a communication protocol interface used in trading operating systems to achieve low-latency data transmission. The UDP interface implements connectionless datagram transmission based on the UDP. Specifically, because the UDP interface can directly send data packets without establishing a connection with the trading intermediary platform, it is suitable for data transmission scenarios with extremely high real-time requirements.

[0107] Specifically, since the transmission of the User Datagram Protocol interface is unidirectional and disordered, all operation requests transmitted through the User Datagram Protocol interface are transaction operation requests. Therefore, the transaction intermediary platform does not need to classify and identify them, but can directly put the target operation requests sent through the User Datagram Protocol interface into the transaction queue.

[0108] Furthermore, for transaction operation requests sent through the User Datagram Protocol interface, since the User Datagram Protocol interface cannot perform reverse data transmission, the transaction result response corresponding to the transaction operation request can be returned to the user end through the Transmission Control Protocol interface.

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

[0110] Optionally, since there is no identity verification operation step during the transmission process of the user datagram protocol interface, the user terminal can be restricted in terms of permissions. That is, the user terminal needs to have permission to use the user datagram protocol interface before it can send a transaction operation request through the user datagram protocol interface.

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

[0112] In the embodiments of this specification, by receiving the target operation request sent by the user terminal through the user datagram protocol interface, there is no need to establish and verify the communication link. By directly placing the target operation request into the transaction queue, an immediate response to high-priority transaction operation requests is achieved in high-frequency trading scenarios, reducing the overhead of establishing and maintaining the communication link, reducing the data transmission delay for the transaction operation request, and ensuring that key transaction operation requests are executed first in the single-threaded architecture, thereby optimizing the dynamic allocation efficiency of system resources while ensuring real-time performance.

[0113] In an optional embodiment of the present specification, the transaction operating system further includes a transaction platform; triggering the sequential retrieval of transaction operation requests from the transaction queue and executing the same includes: sequentially retrieval of transaction operation requests from the transaction queue; processing the transaction operation requests, obtaining transaction operation information, and sending the transaction operation information to the transaction platform; and receiving a transaction result report for the transaction operation information returned by the transaction platform.

[0114] Trading operation information is a standardized data package generated by a trading intermediary platform after receiving and processing a trading operation request. It is used to convey specific trading instructions or operation requirements to the trading platform. Specifically, trading operation information can include key fields such as the trading subject code, trading direction (buy / sell), quantity, and price, and is encapsulated based on the protocol format supported by the trading platform. For example, in a financial trading scenario, when a user submits a trading operation request to "buy 500 lots of stock D," the trading intermediary platform will first verify the user's permissions and account balance, and then convert the request into a trading operation information format that meets the exchange's API interface requirements. For example, a data package containing the stock code "D", the trading direction "buy", the quantity "500", and the price "100.2 yuan" is required for the trading platform to execute the actual trading operation.

[0115] A transaction result report is a data packet of transaction results that the trading platform sends back to the intermediary trading platform after the transaction operation information is actually executed. Specifically, the transaction result report may include fields such as the transaction status (filled / cancelled / failed), the transaction price, the transaction quantity, and the transaction time, used to confirm the final execution of the transaction operation. For example, in a financial transaction scenario, when the trading platform successfully executes a buy request for stock D, it will return a transaction result report indicating that the transaction was completed for 500 lots at 100.2 yuan and may record the transaction timestamp "14:30:45". The intermediary trading platform will then update the user's account status and generate a corresponding transaction report response to return to the user.

[0116] Specifically, the transaction intermediary platform and the transaction platform can transmit data through the preset interface through upstream and downstream quotations, that is, the transaction intermediary platform submits the transaction operation information upstream to the transaction platform, and the transaction platform submits the transaction result report downstream to the transaction intermediary platform.

[0117] Optionally, seat verification can be performed when the trading intermediary platform submits trading operation information to the trading platform. Specifically, a seat is a unique credential within the trading operation system that identifies the trading intermediary platform's legal identity and authority within the trading platform. Seats are typically assigned by trading platforms (such as stock exchanges) and represent the trading intermediary platform's participation qualifications and operational permissions within a specific trading market. Seat verification is a legitimacy check performed by the trading intermediary platform before sending trading operation information to the trading platform to ensure that the initiator of the transaction request has legal trading qualifications. For example, in a financial trading scenario, a securities company's trading intermediary platform must hold the seat number "S12345" assigned by the exchange. When submitting a stock buy order, this seat number must be included for the trading platform to accept and process the request. Otherwise, the request will be deemed illegal and rejected.

[0118] In the embodiments of this specification, by taking out the transaction operation request from the transaction queue and converting the transaction operation request into standardized transaction operation information and sending it to the transaction platform, the transaction intermediary 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 specifications to complete the upward quotation; at the same time, by receiving the transaction result feedback returned by the transaction platform, the transaction intermediary platform can update the execution status of the transaction operation request in real time and generate feedback responses, thereby ensuring the integrity of the transaction operation and the system responsiveness, thereby realizing closed-loop control of the transaction process and dynamic optimization allocation of resources under the single-threaded architecture.

[0119] In an optional embodiment of the present specification, the transaction operating system also includes a user terminal; after receiving the transaction result return for the transaction operation information returned by the transaction platform, it also includes: constructing a transaction return request and placing the transaction return request into a transaction queue; when taking out and executing the transaction return request, processing the transaction result return to obtain a transaction return response; placing the transaction return response into a response return queue; when taking out the transaction return response from the response return queue, returning the transaction return response to the user terminal.

[0120] A transaction report request is an operation request generated by the transaction intermediary platform to provide feedback to the user after receiving the transaction result report from the trading platform. This request is also a high-priority operation request and is secondary to the transaction operation request. Therefore, after constructing a transaction report request, it can be placed in the transaction queue.

[0121] Specifically, the transaction report request may include identification information for the transaction result report, used to identify the corresponding transaction result report. This allows the transaction intermediary platform to process the corresponding transaction result report when removing the transaction report request from the transaction queue and executing it. Optionally, the transaction report request may also include the corresponding user terminal identifier or request sequence number to ensure the correspondence between the transaction result and the original request.

[0122] The transaction return response is the final feedback information returned to the user end after the transaction intermediary platform processes the corresponding transaction result return in the process of extracting and executing the transaction return request.

[0123] Specifically, the transaction response can be formatted and encapsulated based on the core data in the transaction result response. It can also include auxiliary information such as the system processing timestamp and status description to fully present the transaction results. For example, in a financial transaction scenario, after the transaction intermediary platform processes the transaction operation request for stock D, it returns the transaction result response and constructs a transaction response request. During the execution of this transaction response request, a transaction response is generated based on the transaction result response. The content may include "Your buy order for stock D has been executed, the transaction price is 100.2 yuan, the transaction quantity is 500 lots, and the transaction time is 14:30:45", and the system processing timestamp "14:30:48" is attached for display to the user end.

[0124] The response return queue is a buffer queue in the trading operating system used to temporarily store transaction response returns. It is used to decouple the generation and sending processes of transaction response returns, ensuring the orderliness of transaction result feedback and the stability of system response.

[0125] Specifically, the response return queue can follow the first-in-first-out principle, cache the transaction response returns in the order of execution of the transaction response requests, and retrieve them one by one and return them to the user end when the transaction operating system schedules them to the sending stage.

[0126] Optionally, since the communication link between the transaction intermediary platform and the user terminal can be established through a TCP interface, the transaction report response can be returned to the user terminal through the TCP interface.

[0127] Optionally, in addition to the transaction return response corresponding to the transaction operation request, the transaction intermediary platform also needs to return the non-transaction result response corresponding to the non-transaction operation request to the user end. Therefore, the response return queue can also put the non-transaction result response and return it to the user end through the TCP interface.

[0128] For example, in a financial transaction scenario, when the trading platform returns a successful cancellation report for stock E, the transaction intermediary platform will construct a transaction return request based on the transaction result return and put it into the transaction queue; in the process of taking out and executing the transaction return request from the transaction queue, the transaction return response "Your order ORD12345 has been successfully cancelled" can be generated for the key information "Order Number ORD12345", "Order Cancellation Status Successful" and other fields in the transaction result return, combined with the user terminal identifier "ClientX", and the system processing timestamp "15:00:30" is attached to ensure that it is subsequently returned to the correct user terminal; the generated transaction return response is placed in the response response queue, waiting for scheduling by the transaction intermediary platform; in the process of the response response queue being triggered for execution, the transaction intermediary platform will take out the transaction return responses one by one, and return them to the corresponding user terminal through the preset protocol interface (such as the TCP interface), completing the closed-loop feedback of the transaction results.

[0129] In the embodiments of this specification, by constructing a transaction return request based on the transaction result return returned by the transaction platform and placing it in the transaction queue, orderly scheduling and high-priority processing of transaction result feedback are achieved, ensuring that the transaction return response can be generated strictly in accordance with the preset timing logic; by temporarily storing the transaction return response in the response return queue and returning it to the user end, the integrity of the transaction result feedback and the stability of the system response are further guaranteed, thereby realizing closed-loop control of the transaction process and dynamic optimization allocation of resources under a single-threaded architecture.

[0130] In an optional embodiment of the present specification, the transaction operating system also includes a user terminal; triggering the sequential retrieval of non-transaction operation requests from the non-transaction queue and executing them, including: sequentially retrieval of non-transaction operation requests from the non-transaction queue and executing them to obtain non-transaction result responses; placing the non-transaction result responses into a response return queue; and returning the non-transaction result responses to the user terminal when the non-transaction result responses are retrieved from the response return queue.

[0131] A non-trading result response is feedback generated by the trading intermediary platform after executing a non-trading operation request. It is used to convey the results of the non-trading operation to the user. Specifically, the non-trading result response may include the processing status of the non-trading operation request (e.g., success / failure), relevant data (e.g., account balance, position information), and the system processing timestamp, ensuring that the user can accurately obtain the operation result. For example, in a financial transaction scenario, when a user submits a non-trading operation request to "query account balance," the trading intermediary platform will verify user permissions and query account information, generating a non-trading result response that may include "Your account balance is 500,000 yuan, query time 15:10:20" for display to the user.

[0132] Specifically, since the execution of the non-transaction operation request does not need to be processed by the transaction platform, there is no intermediate transition data, and the transaction intermediary platform can directly execute the non-transaction operation request and obtain a non-transaction result response.

[0133] Specifically, since the return priority of non-transaction result responses is low, there is no need to generate corresponding secondary operation requests based on the non-transaction result responses and place them in the transaction queue, so as not to affect the execution of high-priority transaction operation requests or transaction return requests.

[0134] Specifically, non-transaction result responses also need to be returned to the user. Therefore, these responses can be placed in a response return queue and returned to the user upon retrieval. For details on how to retrieve and return non-transaction result responses, refer to the aforementioned example of returning transaction response responses and will not be further elaborated here.

[0135] For example, in a financial transaction scenario, when a user submits a non-transaction operation request of "querying current positions", the transaction intermediary platform will verify the user's identity, and if the verification is passed, retrieve the user's position record from the transaction intermediary platform's database, and generate a position information table based on the position data as a non-transaction result response; when a non-transaction result response is obtained, the non-transaction result response can be placed in a response return queue; in the execution phase of the response return queue, the transaction intermediary platform will take out the non-transaction result responses one by one, and transmit them back to the corresponding user through a preset protocol interface (such as a TCP interface), completing the closed-loop feedback of the operation results.

[0136] In the embodiments of this specification, non-transactional operation requests are sequentially retrieved from a non-transactional queue and executed to obtain non-transactional result responses, which are then placed in a response return queue. This achieves orderly processing of low-priority non-transactional tasks, ensuring that the execution of non-transactional operation requests does not interfere with the real-time performance of high-priority transactional operation tasks. By placing the non-transactional result responses in a response return queue and transmitting them back to the user end based on a preset protocol interface, the generation and feedback processes of the operation results are further decoupled, ensuring the integrity of the non-transactional operation results and the stability of the system response, thereby achieving efficient execution of non-transactional tasks and dynamic optimization allocation of resources under a single-threaded architecture.

[0137] In an optional embodiment of the present specification, the trading operating system further includes a trading platform, and the non-trading operation request includes a market operation request; before sequentially retrieving the non-trading operation request from the non-trading queue and executing it, it also includes: receiving an update market message sent by the trading platform; constructing a market operation request for the update market message, and placing the market operation request into the non-trading queue; triggering the sequential retrieval of the non-trading operation request from the non-trading queue and executing it, including: triggering the retrieval of the market operation request from the non-trading queue and executing it, and updating the market message in the trading intermediary platform based on the update market message.

[0138] Updated market messages are real-time market data packets proactively sent by the trading platform to the intermediary trading platform. Specifically, these messages can include key information such as the latest price, trading volume, and buy and sell orders of the underlying asset, driving the dynamic update of the market data within the intermediary trading platform. Updated market messages can be transmitted via a data transmission link established via a pre-set interface between the trading platform and the intermediary trading platform. Updated market messages can serve as an input data source for market operation requests, ensuring that the intermediary trading platform can respond to market changes promptly. Updated market messages can be sent at pre-set intervals. For example, in a financial trading scenario, when the transaction price of Stock B changes from 100 yuan to 101 yuan, the trading platform will generate and send an Updated Market Message containing Stock B's latest price, trading volume, and timestamp. The intermediary trading platform will then update its local market database based on this information, ensuring that subsequent trading operations are executed based on the latest market information.

[0139] A market operation request is a non-trading operation request generated in the trading operating system based on the market update message sent by the trading platform. It is used to trigger the trading intermediary platform to synchronously update the local market data.

[0140] Specifically, because market updates on the trading intermediary platform require less real-time performance, the market operation requests constructed for updated market information are non-trading operation requests and are placed in the non-trading operation queue after completion. For example, when the trading platform pushes the latest price change information for Stock A, the trading intermediary platform constructs a market operation request based on the updated market information and places it in the non-trading operation queue. During the process of extracting and executing this market operation request from the non-trading operation queue, the trading intermediary platform updates the real-time price of Stock A stored locally, ensuring that the user end or other system modules have access to the latest market data.

[0141] Optionally, although the execution priority of market operation requests is lower than that of trading operation requests and they are placed in the non-trading operation queue, the market information in the trading intermediary platform still needs to be updated in a timely manner. Therefore, in the process of prioritizing the execution of trading operation requests, it is necessary to determine the time window based on the arrival time of the updated trading market information to achieve scheduling balance.

[0142] For example, when the trading platform pushes an updated market information of stock C, which contains fields such as "stock code C", "latest price 105.3 yuan", and "trading volume 2000 lots", the trading intermediary platform will construct a market operation request upon receiving the updated market information. The market operation request may contain the same underlying asset code and updated market data, and attach a timestamp to identify the timeliness of the message, which is used to update the market information in the trading intermediary platform during the execution process; when the market operation request is taken out from the non-trading queue and executed, the trading intermediary platform will update the locally stored stock C price from 104.8 yuan to 105.3 yuan, and simultaneously update the trading volume field to 2000 lots, to ensure that subsequent trading operations (such as placing orders and canceling orders) are based on the latest market status.

[0143] In the embodiments of this specification, by receiving the updated market information sent by the trading platform and constructing a market operation request, the market operation request is placed in a non-trading queue, and when the market operation request is taken out and executed, the market information in the trading intermediary platform is updated based on the updated market information, thereby achieving real-time response to market dynamics and ensuring that local market data is synchronized with the trading platform; on the premise of ensuring the execution of high-priority trading operation requests, the market update task is efficiently processed to avoid untimely market information updates due to long waiting times, thereby achieving the integrity of trading data and dynamic optimization allocation of system resources under a single-threaded architecture.

[0144] The following combined Figure 4 To the attached Figure 5 , taking the application of the operation request execution method provided in this specification in a financial transaction scenario as an example, the operation request execution method is further explained. Figure 4 A schematic diagram of a processing framework of a method for executing an operation request provided by an embodiment of this specification is shown. Figure 5 A flowchart of a processing method for executing an operation request provided by an embodiment of this specification is shown. Specifically, Figure 4 The processing framework shown may include Figure 5 The following steps are shown.

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

[0146] Step 504: In the TCP service module, the target operation request sent by the TCP interface is processed for disconnection processing and request message processing, and the target operation request is placed in the transaction queue and / or non-transaction queue through thread positioning, wherein the transaction queue and the non-transaction queue belong to the working thread.

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

[0148] After executing step 506 , the process includes executing steps 508 to 512 , and / or step 514 , and / or step 516 to 518 .

[0149] Step 508: sequentially retrieve the transaction operation requests from the transaction queue, perform transaction business processing, and send the transaction operation requests to the exchange through asynchronous multi-threaded upward quotation and seat verification.

[0150] Step 510: Receive the return processing returned by the exchange through the downside quotation, generate a corresponding transaction return request, and put it into the transaction queue.

[0151] Step 512: Take the transaction report request from the transaction queue, perform report service processing, and put the transaction report response corresponding to the transaction result report into the response report queue, wherein the response report queue belongs to the TCP service thread.

[0152] Step 514: Take the non-transaction operation request from the non-transaction queue, perform non-transaction business processing, obtain a non-transaction result response, and put it into the response return queue.

[0153] Step 516: Receive the market update message sent by the exchange through the bank quotation using the quotation frequency reduction quotation framework, construct a market operation request, and put it into the non-trading queue.

[0154] Step 518: Take out the market operation request from the non-transaction queue and execute it, and update the market information in the transaction intermediary platform based on the updated market information.

[0155] Step 520: Return the transaction report response and / or non-transaction result response in the response report queue to the user end via the TCP interface.

[0156] In the embodiments of this specification, through the reliability of the TCP interface and the low latency characteristics of the UDP interface, the trading operating system can simultaneously meet the requirements of immediate response to high-priority trading tasks and orderly processing of non-trading tasks; by binding the trading queue and the non-trading queue to a dedicated thread pool and combining the thread positioning mechanism, the real-time nature of key trading operations and the stability of non-trading tasks are ensured; the asynchronous multi-threaded upward quotation and market frequency reduction quotation framework effectively reduces system resource usage, 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 layered architecture design and protocol adaptation strategy realize the differentiated processing of trading operation requests and non-trading operation requests and dynamic resource allocation, and realize the feedback of trading return responses and non-trading result responses through the unified scheduling of the response return queue, thereby realizing efficient closed-loop control of the trading process and dynamic optimization allocation of system resources under the single-threaded architecture.

[0157] Corresponding to the above method embodiment, this specification also provides a transaction operating system embodiment, Figure 6 FIG1 shows a schematic diagram of the structure of a transaction operating system provided by an embodiment of this specification. Figure 6 As shown, the device includes: It includes a user terminal 602, a transaction intermediary platform 604 and a transaction platform 606; The user terminal 602 is used 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; The transaction intermediary platform 604 is configured to obtain a transaction queue and a non-transaction queue, wherein the non-transaction queue has a lower execution priority than the transaction queue; trigger sequentially retrieving and executing transaction operation requests from the transaction queue; if the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, trigger sequentially retrieving and executing 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; if 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 transaction platform 606 is used to receive transaction operation information sent by the transaction intermediary platform 604 and return transaction result feedback; The trading platform 606 is also used to send updated market information to the trading intermediary platform 604.

[0158] The user end is a terminal device or client in a trading operating system that initiates operation requests and receives responses. This can be client software, mobile applications, or web interfaces in financial trading scenarios, or terminal devices in fields such as e-commerce and energy resources. The user end can send trading operation requests (such as placing and canceling orders) or non-trading operation requests (such as query requests and login requests) to the trading intermediary platform and receive transaction feedback or non-trading result responses from the trading intermediary platform.

[0159] The transaction intermediary platform is the core scheduling module of the trading operating system. It is responsible for accessing transaction and non-transaction queues, extracting and executing operation requests from the queues according to pre-set rules. Alternatively, the transaction intermediary platform can receive operation requests and place them into the corresponding queue based on the request type. The transaction intermediary platform processes high-priority transaction operation requests in the transaction queue using a separate thread, while periodically switching to handle low-priority requests in the non-transaction queue to ensure the timeliness of critical business operations.

[0160] A trading platform is a component of a trading operating system responsible for executing trading instructions and returning transaction results. This includes financial trading platforms such as stock exchanges, futures exchanges, and foreign exchange trading platforms, as well as e-commerce and energy resource trading platforms. Trading platforms communicate with intermediary trading platforms via pre-defined protocol interfaces, providing both upstream and downstream quotes. Specifically, the trading platform receives trading operation information from the intermediary platform, completes the actual trading operations, and returns transaction results.

[0161] In the embodiments of this specification, the transaction intermediary platform stores operation requests separately into 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 quantity threshold, avoiding resource waste caused by long-term exclusivity of the transaction queue, and preventing non-transaction tasks from affecting the overall responsiveness of the system due to long-term non-execution; refines the switching logic of the execution queue through a time window mechanism to ensure priority processing of transaction tasks, and switches to executing non-transaction operation requests when market data is updated to avoid long waiting times, thereby realizing differentiated processing of transaction operation requests and non-transaction operation requests and dynamic resource allocation, and realizing accurate feedback of transaction results and non-transaction results through unified scheduling of response return queues and reliable transmission of TCP interfaces, thereby achieving efficient closed-loop control of the transaction process and dynamic optimization allocation of system resources under a single-threaded architecture, taking into account both the timeliness of key transaction tasks and the stability of non-transaction tasks.

[0162] Optionally, the transaction intermediary platform further includes a request scheduling module, a request execution module, and an uplink and downlink module; The request scheduling module is used to receive operation requests sent by the user end and put them into the transaction queue or non-transaction queue; a request execution module, configured to sequentially retrieve and execute transaction operation requests from the transaction queue; trigger, when the number of executed transaction operation requests reaches a first preset number, to sequentially retrieve and execute non-transaction operation requests from the non-transaction queue; and jump to sequentially retrieving and executing transaction operation requests from the transaction queue when the number of executed non-transaction operation requests reaches a second preset number and the transaction queue is not empty; The upstream and downstream modules are used to send transaction operation messages to the trading platform and receive transaction result feedback from the trading platform; The uplink and downlink modules are also used to receive updated market information sent by the trading platform.

[0163] The request scheduling module is the core component of the transaction intermediary platform responsible for receiving and classifying operation requests, assigning them to the corresponding transaction queue or non-transaction queue based on their type. Specifically, the request scheduling module parses the operation classification identifier in the operation request sent by the user, determines its priority and processing logic, and then places transaction requests into the transaction queue and non-transaction requests into the non-transaction queue based on pre-set rules.

[0164] The request execution module is the core execution unit within the transaction intermediary platform, responsible for dynamically scheduling and executing transaction requests. It sequentially retrieves and executes transaction requests from the transaction queue, while also controlling the switching between the transaction queue and the non-transaction queue based on a preset threshold. Specifically, when the number of transaction requests reaches a first preset threshold, the request execution module proactively triggers the execution process in the non-transaction queue, freeing up system resources and ensuring the responsiveness of lower-priority tasks. When the number of non-transaction requests reaches a second preset threshold and the transaction queue is not empty, the request execution module immediately switches back to the transaction queue, prioritizing higher-priority transaction requests.

[0165] The Uplink / Downlink module is the core communication component within the trading intermediary platform responsible for data exchange with the trading platform. It is used to submit trade operation information to the trading platform and receive feedback on trade results from the trading platform. It is also used to receive market updates from the trading platform. Specifically, the Uplink / Downlink module establishes a connection with the trading platform through a pre-set interface, completes seat verification for trade operation requests, encapsulates and transmits data, and receives feedback based on the exchange's interface.

[0166] In the embodiments of this specification, the request scheduling module ensures the physical isolation of trading and non-trading tasks by parsing the operation classification identifiers and allocating queues, thereby preventing low-priority operation requests from blocking and interfering with high-priority operation requests; the request execution module implements a dynamic switching mechanism based on a preset quantity threshold, combined with time window judgment logic, to achieve cyclic processing of trading queues and non-trading queues under a single-threaded architecture, taking into account the real-time performance of high-priority tasks and the responsiveness of low-priority tasks; the uplink and downlink modules ensure the reliability of trading instructions and the synchronization of market information through standardized uplink and downlink quotation and market information receiving mechanisms; it realizes the accurate classification, dynamic scheduling and efficient execution of operation requests in the trading operating system, and optimizes system resource allocation.

[0167] The above is a schematic diagram of a transaction operating system according to this embodiment. It should be noted that the technical solution of this transaction operating system and the technical solution of the aforementioned operation request execution method are based on the same concept. For details not described in detail in the technical solution of the transaction operating system, please refer to the description of the technical solution of the aforementioned operation request execution method.

[0168] Figure 7 7 shows a block diagram of a computing device 700 according to one embodiment of the present disclosure. 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 via a bus 730, and a database 750 is used to store data.

[0169] Computing device 700 also includes an access device 740 that enables 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 a combination of communication networks such as the Internet. Access device 740 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0170] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 7 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0171] Computing device 700 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, personal digital assistant, laptop computer, notebook computer, netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or personal computer (PC). Computing device 700 can also be a mobile or stationary server.

[0172] The processor 720 is configured to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-mentioned operation request execution method.

[0173] The above is a schematic diagram of a computing device according to this embodiment. It should be noted that the technical solution of the computing device and the technical solution of the aforementioned operation request execution method are based on the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the aforementioned operation request execution method.

[0174] An embodiment of the present specification further provides a computer-readable storage medium storing a computer program / instruction. When the computer program / instruction is executed by a processor, the steps of the above-mentioned operation request execution method are implemented.

[0175] The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the aforementioned operation request execution method are based on the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the aforementioned operation request execution method.

[0176] An embodiment of the present specification further provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned operation request execution method when executed by a processor.

[0177] The above is an illustrative solution of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned operation request execution method are based on the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the aforementioned operation request execution method.

[0178] 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.

[0179] 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.

[0180] 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 transaction operation requests reaches a first preset number and a preset time condition is satisfied, triggering sequential retrieval of non-transaction operation requests from the non-transaction queue and execution thereof, wherein the execution priority of the non-transaction operation requests is lower than that of the transaction operation requests; 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; if the number of executed transaction operation requests reaches a first preset number and a preset time condition is satisfied, trigger sequentially retrieving and executing 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; if 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