Cloud-native-based top-speed transaction system, method, device, medium and product

Abstract

The invention discloses a top-speed transaction system, method, device, medium and product based on cloud native, and relates to the technical field of computer network communication, the system comprises a reliable multicast bus packaged in a Docker container and at least one serial assembly line arranged in a micro-service architecture, and any serial assembly line is provided with a plurality of service processing units. The reliable multicast bus is used for receiving external instruction information and sending the instruction information to the service processing unit; and the service processing unit is used for executing preset service logic operation on the instruction information to obtain an operation result, transmitting the operation result to the next service processing unit of the same serial pipeline through the lock-free message queue, obtaining operated instruction information after all the service processing units finish operation, and sending the operated instruction information to the next service processing unit of the same serial pipeline through the lock-free message queue. The operated instruction information is fed back to the reliable multicast bus; and the reliable multicast bus is used for receiving and outputting the operated instruction information. The research and development efficiency of the top-speed transaction system is improved.

Description

Technical Field

[0001] The present application relates to the field of computer network communication technology, and in particular to cloud-native-based ultra-fast trading systems, methods, devices, media and products. Background Art

[0002] When building a complex trading business system, it is usually necessary to carry out mature modular division of orders, positions, risk control, routing, etc. according to the boundaries of the domain to realize the processing of multiple order events, multiple capital entities, multiple risk rules, and multiple order routes; the current mainstream ultra-fast trading technology solutions usually integrate these modules into a business processing unit to achieve ultra-fast trading with low latency, high reliability, and strong data consistency; however, since such solutions integrate all business functions into one business processing unit, the systems constructed by such solutions are highly complex, have low throughput, and are difficult to expand functions. The interaction of these factors ultimately leads to the problem of low R&D efficiency of ultra-fast trading systems. Summary of the invention

[0003] The main purpose of this application is to provide a cloud-native-based ultra-fast trading system, method, device, medium and product, aiming to solve the technical problem of low R&D efficiency of the ultra-fast trading system.

[0004] To achieve the above-mentioned purpose, the present application proposes a cloud-native-based ultra-fast trading system, the cloud-native-based ultra-fast trading system comprising a reliable multicast bus encapsulated in a Docker container, and at least one serial pipeline arranged in a microservice architecture, wherein a plurality of business processing units are arranged in any serial pipeline, and the plurality of business processing units are connected in series in sequence;

[0005] A reliable multicast bus, used to receive external command information and send the command information to the business processing unit;

[0006] The business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform preset business logic operations on the instruction information, obtain the operation results, and transmit the operation results to the next business processing unit of the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operation, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation;

[0007] A reliable multicast bus is used to receive calculated instruction information and output calculated instruction information.

[0008] In one embodiment, the cloud-native ultra-fast trading system also includes a master-slave arbitration module, the microservice architecture includes multiple microservices, and the multiple microservices are connected to the master-slave arbitration module, and the serial pipelines in the multiple microservices are connected to a reliable multicast bus.

[0009] In one embodiment, applied to a cloud-native-based ultra-fast trading system, the cloud-native-based ultra-fast trading method includes:

[0010] Receive external instruction information through a reliable multicast bus in the cloud-native ultra-fast trading system;

[0011] The business processing unit in the cloud-native ultra-fast trading system performs preset business logic operations on the instruction information to obtain the operation results, and transmits the operation results to the next business processing unit belonging to the same serial pipeline through a preset lock-free message queue, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation;

[0012] After all the business processing units have completed the operations, the operated instruction information is obtained and the operated instruction information is output according to the reliable multicast bus.

[0013] In one embodiment, the step of executing a preset business logic operation on the instruction information by the business processing unit in the cloud-native high-speed trading system includes:

[0014] Each business processing unit in the cloud-native ultra-fast trading system is associated with a scheduling thread. The scheduling thread calls the preset business logic operation to perform logical operations on the instruction information to obtain the operation results. Each scheduling thread is configured with a CPU affinity setting and is bound to the preset CPU NUMA node.

[0015] In one embodiment, the cloud-native-based ultra-fast transaction method further includes:

[0016] Monitor whether there is a main microservice among multiple microservices in the microservice architecture;

[0017] If there is a master microservice among the multiple microservices, determine a slave microservice among the other microservices except the master microservice among the multiple microservices, wherein the other microservice sends a service request to the master-slave arbitration module to become a slave microservice, and after receiving a successful response from the master-slave arbitration module to the service request, sends a synchronization message request to the master microservice, and if the other microservice receives a synchronization message returned by the master microservice, the other microservice is determined to be a slave microservice;

[0018] The steps of performing preset business logic operations on the instruction information through the business processing unit in the cloud-native high-speed trading system to obtain the operation results include:

[0019] The business processing unit in the main microservice performs a preset business logic operation on the instruction information to obtain the operation result, and when an abnormality is detected in the main microservice, the business processing unit in the slave microservice performs a preset business logic operation on the instruction information to obtain the operation result.

[0020] In one embodiment, the step of monitoring whether a main microservice exists in a plurality of microservices of a microservice architecture includes:

[0021] If there is no master microservice among the multiple microservices, the master microservice among the multiple microservices is determined according to the master-slave arbitration module, and the business processing unit in the master microservice performs a preset business logic operation on the instruction information to obtain an operation result.

[0022] In one embodiment, the step of monitoring whether there is a main microservice in multiple microservices of the microservice architecture includes:

[0023] When it is detected that at least one microservice has been successfully started, determining whether the microservice is in a preset replay mode;

[0024] If it is in replay mode, read the preset target sequence number of the largest consumed message, set the preset starting sequence number of the replay message to the target sequence number plus one, and start replaying.

[0025] In addition, to achieve the above-mentioned purpose, the present application also proposes a device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the cloud-native-based ultra-fast trading method as described above.

[0026] In addition, to achieve the above-mentioned purpose, the present application also proposes a medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the cloud-native-based ultra-fast trading method as described above are implemented.

[0027] In addition, to achieve the above-mentioned purpose, the present application also provides a product, which is a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps of the cloud-native based ultra-fast trading method as described above.

[0028] One or more technical solutions proposed in this application have at least the following technical effects:

[0029] This application provides a cloud-native high-speed trading system, including a reliable multicast bus encapsulated in a Docker container, at least one serial pipeline set in a microservice architecture, multiple business processing units set in any serial pipeline, and the business processing units are connected in sequence. By using Docker container technology, the reliable multicast bus library is encapsulated, the complex and diverse host environment affects the version compatibility of the reliable multicast bus library, the application scope of the reliable multicast bus is expanded, and the compatibility and release efficiency of multiple operating system versions of microservices are improved. Native support for low-latency and high-reliability multicast communication in the Docker virtual environment allows developers to quickly integrate reliable multicast buses and build a low-latency and high-reliability architecture as long as they are familiar with Docker container applications. The reliable multicast bus is used to receive external instruction information and send the instruction information to the business processing unit, receive the calculated instruction information sent by the business processing unit, and output the calculated instruction information, thereby realizing the stable transmission of cross-process end-to-end messages; the business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform preset business logic operations on the instruction information, obtain the operation results, and transmit the operation results to the next business processing unit in the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operations, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus. Relying on the multicast bus, in which the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to different business logic operations. By using the business processing unit concurrency model, flexible decoupling of multiple business modules is achieved. Each business logic operation is carried by an independent business processing unit and allocated independent thread scheduling, which significantly improves the system's processing capacity and response speed. The circular message queue is used between the business processing units on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, order, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, and completing the association between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy order, must-reach, and traceability capabilities in the reliable multicast bus message transmission process, the distributed pipeline microservices and microservices can be achieved with reliable multi-activity at a low cost. Developers use assembly-style, lock-free programming and focus on the implementation of the business logic of each business processing unit. They can complete multi-active microservice development for ten-microsecond transaction event processing and cross-process data transmission, thereby avoiding the problem of solving heavy technical problems such as high concurrency congestion, data communication reliability, memory data consistency, and high service availability in the ultra-fast trading system, which can effectively improve the efficiency of the ultra-fast trading system. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0031] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 This is a schematic diagram of the current technical implementation of the extreme speed trading system;

[0033] Figure 2 This is another technical implementation diagram of the current ultra-fast trading system;

[0034] Figure 3 This is the architecture design diagram of the first embodiment of the cloud-native ultra-fast trading system of this application;

[0035] Figure 4 This is a flow chart of the second embodiment of the cloud-native-based ultra-fast transaction method of this application;

[0036] Figure 5 This is a flow chart of pipeline information processing for the cloud-native ultra-fast trading method of this application;

[0037] Figure 6 This is a flow chart of the third embodiment of the cloud-native-based ultra-fast transaction method of this application;

[0038] Figure 7 This is the UML diagram of the cloud-native high-speed trading system for this application;

[0039] Figure 8 This is another UML diagram of the cloud-native-based ultra-fast trading system for this application;

[0040] Fig. 9 This is another UML diagram of the cloud-native-based ultra-fast trading system for this application;

[0041] Fig.10 This is another UML diagram of the cloud-native-based ultra-fast trading system for this application;

[0042] Fig.11 This is a schematic diagram of the device structure of the hardware operating environment involved in the cloud-native based ultra-fast trading method in the embodiment of the present application.

[0043] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0045] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0046] The extremely fast technical solution based on reliable multicast bus and microservice architecture supports complex over-the-counter derivatives trading business. When it needs to support complex transactions in multiple business modules such as contract trading, capital and securities control, pre-risk control, over-the-counter matching, hedging transactions, etc., there are usually two implementation methods:

[0047] (1) Figure 1 As shown, an application (microservice) is implemented for each business module, and each application completes the logical operation of a single business module through a single business processing unit (business processing unit 1, business processing unit 2, business processing unit 3). Data communication between the applications is carried out through a reliable multicast bus and Linux (an operating system) operating system and kernel bypass. However, this method has the technical disadvantages of lengthy transaction link network and large transaction delay;

[0048] (2) Figure 2 As shown, multiple business modules are integrated into one application, and this application completes the logical operations of multiple business modules (business function 1, business function 2, business function 3) through a business processing unit. However, this method has the technical disadvantages of complex logic of a single business processing unit, difficulty in function expansion, and low service throughput.

[0049] In view of the above technical shortcomings, this embodiment aims to optimize the existing reliable multicast bus technology, by integrating the Docker (a container engine) container and the business processing unit concurrent model, and performing four key extension optimizations to improve system performance and communication efficiency. First, the multicast bus library is encapsulated using Docker container technology to achieve low-latency preheating, multi-thread synchronization and message persistence, ensure the isolation and consistency of different application environments, and optimize message forwarding and multicast communication. Secondly, by creating independent business processing units, each business processing unit is responsible for a single business logic, and the decoupling and efficient concurrent processing of business modules are achieved. Third, an independent scheduling thread is allocated to each business processing unit, the CPU (central processing unit) affinity is set, and it is bound to the NUMA (Non-Uniform Memory Access) core of the CPU to reduce thread switching overhead, increase the CPU access memory speed, and achieve business processing at the ten-microsecond level. Finally, the business processing unit is registered to the serial pipeline in the order of dependency, and nanosecond data interaction is achieved through a lock-free queue, keeping the business function intact, reducing processing delays, and improving system throughput. In addition, the integrated reliable multicast bus is based on the UDP (User Datagram Protocol) protocol, integrating message confirmation / retransmission, forward error correction, congestion control and other mechanisms to achieve stable, efficient and reliable transmission of end-to-end messages. At the same time, the core penetration technology is introduced to reduce the number of data copies, CPU usage and latency by processing network data packets in user space, and achieve low-latency and high-throughput communication across hosts. These optimization measures have jointly improved the R&D efficiency and operational performance of the extreme trading system.

[0050] Based on this, an embodiment of the present application provides a cloud-native based ultra-fast trading system.

[0051] In this embodiment, the cloud-native-based ultra-fast trading system includes a reliable multicast bus encapsulated in a Docker container, and at least one serial pipeline arranged in a microservice architecture, wherein a plurality of business processing units are arranged in any serial pipeline, and the plurality of business processing units are sequentially connected in series;

[0052] A reliable multicast bus, used to receive external command information and send the command information to the business processing unit;

[0053] The business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform preset business logic operations on the instruction information, obtain the operation results, and transmit the operation results to the next business processing unit of the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operation, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation;

[0054] A reliable multicast bus is used to receive calculated instruction information and output calculated instruction information.

[0055] In this embodiment, the reliable multicast bus is a message transmission system built on the basis of the native UDP multicast communication protocol, and the reliable multicast bus is provided with a message confirmation / retransmission mechanism, a forward error correction technology, a congestion control algorithm, a master / slave message sequencing mechanism, and a multi-copy persistent traceability mechanism. The reliable multicast bus can realize the stable, efficient, and reliable transmission of cross-process end-to-end messages, use the message confirmation / retransmission mechanism to ensure the stability and arrival of message transmission, use the forward error correction technology to reduce the number of message retransmissions, and adjust the sending rate through the congestion control algorithm, and at the same time combine the master / slave message sequencing mechanism and the multi-copy persistent traceability mechanism to realize the traceability of data and the reliable and orderly transmission of multiple copies of messages.

[0056] A Docker container is a virtualized operating environment based on Docker technology. A reliable multicast bus library and its deeply optimized components are set up in the Docker container. The Docker container can ensure the isolation of different microservice operating environments, as well as the consistency of system library dependencies and bus library dependency versions of the same microservice base image, while achieving low-latency and highly reliable multicast communication.

[0057] The serial pipeline can be a serial pipeline processing mechanism, in which a registration mechanism for registering and managing business processing units and a pipeline processing mechanism for controlling the transmission of messages between business processing units are set. The serial pipeline can ensure that each business processing unit registers and transmits messages in a preset dependency order, and realizes lock-free, low-latency, and parallel execution of the entire business processing process.

[0058] The business processing unit can be a processing unit that independently processes the logic of a single business module. The business processing unit is equipped with independent data cache space, lock-free message queue, independent scheduling thread and thread affinity. Furthermore, the scheduling thread can be bound to the NUMA processing core of the specified CPU to increase processing efficiency. The business processing unit can realize flexible decoupling of multiple business modules, and each business processing unit only processes the logical operations of a single business module.

[0059] In this embodiment, when the instruction information sent by the outside (or other internal reliable multicast buses) arrives at the system, it is first received by the reliable multicast bus and passed to the first business processing unit in the serial pipeline. After the business processing unit calculates the instruction information, it sends the instruction information to the business processing unit registered on the same serial pipeline as it according to the preset dependency order. Each business processing unit calculates the instruction information in turn and passes the processing result to the next business processing unit through the lock-free message queue. When all business processing units have completed the processing, the last business processing unit on the serial pipeline returns the calculated instruction information to the reliable multicast bus, and finally the reliable multicast bus sends the calculated instruction information to the external system or performs the next step of processing.

[0060] This embodiment provides a cloud-native high-speed trading system, including a reliable multicast bus encapsulated in a Docker container, at least one serial pipeline set in a microservice architecture, multiple business processing units set in any serial pipeline, and the business processing units are connected in sequence. By using Docker container technology, the reliable multicast bus library is encapsulated, the complex and diverse host environment affects the version compatibility of the reliable multicast bus library, the application scope of the reliable multicast bus is expanded, and the compatibility and release efficiency of multiple operating system versions of microservices are improved. Native support is provided in the Docker virtual environment to achieve low-latency and high-reliability multicast communication, so that developers can quickly realize the integration of reliable multicast buses and complete the construction of low-latency and high-reliability architectures as long as they are familiar with Docker container applications. The reliable multicast bus is used to receive external instruction information and send the instruction information to the business processing unit, receive the calculated instruction information sent by the business processing unit, and output the calculated instruction information, thereby realizing the stable transmission of cross-process end-to-end messages; the business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform preset business logic operations on the instruction information, obtain the operation results, and transmit the operation results to the next business processing unit in the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operations, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus. Relying on the multicast bus, in which the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to different business logic operations. By using the business processing unit concurrency model, flexible decoupling of multiple business modules is achieved. Each business logic operation is carried by an independent business processing unit and allocated independent thread scheduling, which significantly improves the system's processing capacity and response speed. The circular message queue is used between the business processing units on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, order, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, and completing the association between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy order, must-reach, and traceability capabilities in the reliable multicast bus message transmission process, the distributed pipeline microservices and microservices can be achieved with reliable multi-activity at a low cost. Developers use assembly-style, lock-free programming and focus on the implementation of the business logic of each business processing unit. They can complete multi-active microservice development for ten-microsecond transaction event processing and cross-process data transmission, thereby avoiding the problem of solving heavy technical problems such as high concurrency congestion, data communication reliability, memory data consistency, and high service availability in the ultra-fast trading system, which can effectively improve the efficiency of the ultra-fast trading system.

[0061] In a feasible implementation, the cloud-native-based extreme-speed trading system further includes a master-slave arbitration module, the microservice architecture includes a plurality of microservices, and the plurality of microservices are connected to the master-slave arbitration module, and the serial pipelines in the plurality of microservices are connected to a reliable multicast bus;

[0062] The master-slave arbitration module is a key component used to arbitrate the master and slave status of multiple microservices in cluster mode. After the master-slave arbitration, multiple microservices in the cluster obtain a microservice status of one master and multiple slaves. The master-slave arbitration module is set with cluster configuration information and message sequencing rules. It can send configuration information and sequencing rules to the master and slave microservices of the cluster, and the master microservice will queue and sequence the messages received from the multicast bus. The master microservice will synchronize the queued and sequenced message sequence to the slave microservice, thereby ensuring reliable and orderly transmission and synchronization of messages between multiple copies in the service cluster.

[0063] Microservice architecture can be a distributed service framework that contains multiple microservices. Each microservice is an independent business unit that can be deployed and expanded independently, responsible for processing specific business logic. Microservices in the microservice architecture are divided into master services and slave services. The master service is responsible for coordinating and managing other services in the cluster, processing key business logic and decision-making, and the slave service is responsible for executing the tasks assigned by the master service, such as data synchronization, status update, etc. If necessary, the slave service can be a backup of the master service, and can take over the work of the master service when the master service fails.

[0064] First, the microservice is started through the Docker container. The microservice will monitor whether there is a master microservice belonging to the main service among the multiple microservices in the microservice architecture. If not, the microservice will communicate with the master-slave arbitration module and apply to become the master microservice. It will receive the instruction information from the reliable multicast bus through the business processing unit in the serial pipeline and start processing. The business processing unit passes the processing results to the next business processing unit in the pipeline through a lock-free message queue until all business logics are completed. When all business processing units complete the processing, the processed instruction information will be sent back to the microservice through the reliable multicast bus, and then the microservice will feed back to the external system or other microservices.

[0065] If there is a master microservice, the microservice runs as a slave service. It will send a synchronization message request to the master service and update its own status after receiving the synchronization message from the master service.

[0066] For example, refer to Figure 3In the system, there are master applications (i.e., master microservices) and slave applications (i.e., slave microservices) to process information. They are connected and interacted with each other through serial pipelines and reliable multicast buses. As the core node of the system, the master application is responsible for processing key business logic. The data flow first enters the serial pipeline in the master application, which contains business processing units 1, 2, and 3 arranged in sequence. Each unit performs a specific business operation and passes the processing results to the next unit. The communication of the system relies on a reliable multicast bus, which ensures that messages are transmitted stably and reliably between the master and slave application nodes. This mechanism is crucial to maintaining data consistency and synchronization of system status. In order to optimize network communication, the system uses Docker container technology and kernel bypass technology. This technology combines the isolation of Docker containers with the efficient data processing capabilities of kernel bypass, allowing data to be processed directly in user space, bypassing the traditional kernel network stack, thereby reducing communication latency and improving data throughput. The master-slave arbitration center (i.e., the master-slave arbitration module) is a key component of the system, responsible for monitoring and maintaining the roles and status of master and slave applications. It ensures that only one application is the master application performing critical operations at any time, while the other applications are on standby as slave applications. If the master application fails, the master-slave arbitration center will quickly elect a new master application to ensure the continuity and high availability of the system. The slave application acts as a backup under normal circumstances, listening to status updates from the master-slave arbitration center, ready to take over the responsibilities of the master application when needed. After the data is processed and synchronized in the master application, the slave application can receive this data, ensuring seamless takeover in the event of a failure of the master application.

[0067] This embodiment achieves efficient and reliable service coordination and data processing by introducing a master-slave arbitration module and a microservice architecture. The master-slave arbitration module ensures that messages can be reliably and orderly transmitted and synchronized between multiple copies in the service cluster, avoiding data inconsistency and conflict. The microservice architecture improves the flexibility and maintainability of the system by splitting the business logic into multiple independent, deployable and scalable microservices. In addition, the microservice intelligently applies to become a master microservice or a slave microservice by monitoring the existence of the master microservice, thereby achieving automatic load balancing and failover of the service. When the microservice is used as the master microservice, it can efficiently process business logic operations and promptly feed back the processing results to external systems or other microservices. When the microservice is used as a slave microservice, it can synchronize the status to the master microservice in a timely manner to ensure the consistency and reliability of the service. This design not only improves the processing speed and responsiveness of the system, but also enhances the stability and availability of the system.

[0068] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be repeated later.

[0069] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a terminal system, etc. that can realize the above functions. The following takes the cloud-native-based extreme speed trading system (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0070] This embodiment also provides a cloud-native-based ultra-fast trading method, which is applied to a cloud-native-based ultra-fast trading system. The cloud-native-based ultra-fast trading system includes a reliable multicast bus encapsulated in a Docker container, at least one serial pipeline set in a microservice architecture, and multiple business processing units are set in any serial pipeline, and the business processing units are connected in sequence, referring to Figure 4 , Figure 4 This is a flow chart of the second embodiment of the cloud-native-based ultra-fast trading method of this application. The cloud-native-based ultra-fast trading method includes steps S10 to S30:

[0071] Step S10, receiving external instruction information through a reliable multicast bus in the cloud-native ultra-fast trading system;

[0072] It should be noted that instruction information is data or signals to be processed in the system, and usually includes specific operations to be performed and related data.

[0073] The system first receives instruction information from the outside through a reliable multicast bus. This step involves network communication, in which the reliable multicast bus uses its built-in communication protocol to ensure that the instruction information can reliably reach the system even when the network is unstable. After receiving the instruction information, the reliable multicast bus passes this information to the business processing unit in the serial pipeline.

[0074] Step S20, the business processing unit in the cloud-native ultra-fast trading system performs a preset business logic operation on the instruction information to obtain a calculation result, and transmits the calculation result to the next business processing unit belonging to the same serial pipeline through a preset lock-free message queue, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation;

[0075] It should be noted that the lock-free message queue is a thread-safe message queue that allows multiple threads to read and write data concurrently without locking, reducing lock contention and improving processing efficiency.

[0076] There are many serial pipelines in the microservice architecture, and there are multiple business processing units in the serial pipeline. The reliable multicast bus can select a target serial pipeline according to the preset program settings. The business processing units in the target serial pipeline pass the instruction information to each business processing unit registered on the target serial pipeline in sequence according to the dependency relationship between the business processing units. Each business processing unit performs specific business logic operations on the instruction information. This step involves the specific processing of data. The business processing unit calculates or converts the data according to the preset rules to generate the operation results.

[0077] Step S30, after all the service processing units have completed the calculation, the calculated instruction information is obtained, and the calculated instruction information is output according to the reliable multicast bus.

[0078] It should be noted that the calculated instruction information is the instruction information processed by the business processing unit and may include the result of the business logic operation.

[0079] When all business processing units in the serial pipeline have completed processing the instruction information in turn, the processed information is returned to the reliable multicast bus. This step marks the end of the data processing flow, and the calculated instruction information now contains the calculation results of all business processing units. Finally, the reliable multicast bus sends the processed information to an external system or other reliable multicast bus for subsequent processing. This step may involve sending the result data back to the original requester, or storing it in an in-memory database for use by other system components or further analysis.

[0080] For example, refer to Figure 5 , when a new message (message-1-2-3-4) is received by the reliable multicast bus and enters the system, the message first enters the first business processing unit 1. This unit performs a series of operations, such as verification, preprocessing, etc., to obtain message-1-2-3. Then message-1-2-3 is passed to the next stage. The message passes through multiple business processing units in the order of the serial pipeline. Each business processing unit completes its specific task and then passes the message to the next business processing unit: business processing unit 2 obtains message-1-2, and business processing unit 3 obtains message-1. After passing through all business processing units, the message is passed to the reliable multicast bus, which sends the processed message-1 to the source of message-1-2-3-4. At the same time, the system interacts with the database for message-1. This may mean that the data contained in the message is stored in the in-memory database, or additional data is retrieved from the in-memory database to complete the processing of the message.

[0081] This embodiment provides a cloud-native high-speed trading system, including a reliable multicast bus encapsulated in a Docker container, at least one serial pipeline set in a microservice architecture, multiple business processing units set in any serial pipeline, and the business processing units are connected in sequence. By using Docker container technology, the reliable multicast bus library is encapsulated, the complex and diverse host environment affects the version compatibility of the reliable multicast bus library, the application scope of the reliable multicast bus is expanded, and the compatibility and release efficiency of multiple operating system versions of microservices are improved. Native support is provided in the Docker virtual environment to achieve low-latency and high-reliability multicast communication, so that developers can quickly realize the integration of reliable multicast buses and complete the construction of low-latency and high-reliability architectures as long as they are familiar with Docker container applications. The reliable multicast bus is used to receive external instruction information and send the instruction information to the business processing unit, receive the calculated instruction information sent by the business processing unit, and output the calculated instruction information, thereby realizing the stable transmission of cross-process end-to-end messages; the business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform preset business logic operations on the instruction information, obtain the operation results, and transmit the operation results to the next business processing unit in the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operations, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus. Relying on the multicast bus, in which the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to different business logic operations. By using the business processing unit concurrency model, flexible decoupling of multiple business modules is achieved. Each business logic operation is carried by an independent business processing unit and allocated independent thread scheduling, which significantly improves the system's processing capacity and response speed. The circular message queue is used between the business processing units on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, order, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, and completing the association between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy order, must-reach, and traceability capabilities in the reliable multicast bus message transmission process, the distributed pipeline microservices and microservices can be achieved with reliable multi-activity at a low cost. Developers use assembly-style, lock-free programming and focus on the implementation of the business logic of each business processing unit. They can complete multi-active microservice development for ten-microsecond transaction event processing and cross-process data transmission, thereby avoiding the problem of solving heavy technical problems such as high concurrency congestion, data communication reliability, memory data consistency, and high service availability in the ultra-fast trading system, which can effectively improve the efficiency of the ultra-fast trading system.

[0082] In a feasible implementation, step S20 may include step T10:

[0083] Step T10, each business processing unit in the cloud-native ultra-fast trading system is associated with a scheduling thread, and the scheduling thread calls the preset business logic operation to perform logical operations on the instruction information to obtain the operation results, wherein each scheduling thread is configured with a CPU affinity setting and is bound to the preset CPU NUMA node.

[0084] It should be noted that the scheduling thread is a thread used to manage and schedule the work of the business processing unit to ensure that the business logic can be executed in the expected order and priority. CPU affinity setting is a technology that binds threads or processes to specific CPU cores to reduce the overhead caused by thread migration, improve CPU cache hit rate, and thus improve performance. NUMA nodes are memory and processor combination units in the Non-Uniform Memory Access architecture. The processor in each NUMA node accesses local memory faster than accessing the memory of other nodes.

[0085] First, in the extreme speed trading system, each business processing unit is assigned a scheduling thread. This scheduling thread is the execution engine of the business processing unit, responsible for calling the preset business logic operation to process the instruction information according to the system requirements. The instruction information may be a transaction request, market data update or other business events that need to be processed by the system. In order to improve the performance of the system, each scheduling thread is configured with CPU affinity settings. When the system receives the instruction information, the corresponding scheduling thread will perform a logical operation on the instruction information according to the preset business logic operation. In this process, the scheduling thread will make full use of the performance advantages of the CPU and NUMA node to which it is bound to ensure that the logical operation can be completed quickly and accurately. Finally, the scheduling thread returns the operation result to the system, and the system performs subsequent operations based on the operation result, such as updating the transaction status, sending transaction confirmation, etc.

[0086] This embodiment reduces the thread context switching overhead and improves the CPU cache hit rate by setting independent scheduling threads and thread affinity; binds the scheduling thread to the NUMA processing core of the specified CPU, combines the NUMA cache acceleration mechanism, improves the CPU access speed, and realizes the exclusive operation of the scheduling thread on the CPU and tens of microseconds of business processing.

[0087] Based on the first or second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as the first or second embodiment can refer to the above introduction, and will not be repeated later. The cloud-native-based high-speed transaction method also includes steps A10 to A20:

[0088] Step A10, monitoring whether there is a main microservice among multiple microservices in the microservice architecture;

[0089] It should be noted that monitoring refers to the system or program actively monitoring specific events or changes in status. Here, it refers to monitoring the master-slave status of each microservice in the cluster. In a distributed microservice architecture, there are multiple microservices, and there is a master-slave role allocation between these microservices. Usually, there is a master microservice responsible for handling key tasks, while the slave microservice may be responsible for backup or auxiliary tasks. The master microservice refers to the node in the service cluster that is responsible for the main business logic processing or service provision, and has higher stability and reliability requirements.

[0090] After starting a microservice in the microservice architecture, the microservice will first enter the state of monitoring whether there is a master microservice among other microservices. If it is impossible to monitor whether there is a master microservice, you can query or subscribe to these status information from the master-slave arbitration module to understand which microservices in the current service cluster are master services and which are backup or slave services.

[0091] Step A20, if there is a master microservice among the multiple microservices, determine a slave microservice among the other microservices except the master microservice among the multiple microservices, wherein the other microservice sends a service request to the master-slave arbitration module to become a slave microservice, and after receiving a successful response from the master-slave arbitration module to the service request, sends a synchronization message request to the master microservice, and if the other microservice receives a synchronization message returned by the master microservice, the other microservice is determined to be a slave microservice;

[0092] It should be noted that, corresponding to the master microservice, the slave microservice refers to a service node that follows the master microservice, receives and processes message events synchronized from the master service. In the service cluster mode, the slave service can realize the backup and expansion of the master service, improving the availability and throughput of the system. In the trading system, message events refer to information generated by various business operations that need to be processed or recorded by the system. These events may include order submission, position changes, risk control triggers, etc.

[0093] First, if the microservice learns from the master-slave arbitration center that there is a master microservice in the cluster and it is running normally, it will be changed to the standby slave microservice state and start synchronizing message events to the master microservice. These events may include various business data and state changes generated by the microservice during operation. The synchronization process is usually implemented through a reliable multicast bus to ensure that messages can be transmitted from the master microservice to the standby slave microservice stably and efficiently. After the standby slave microservice completes synchronizing message events to the master microservice, the microservice is changed to a slave microservice. This step is implemented through the service internal state machine. After being set as a slave microservice, the microservice will begin to receive and process message events synchronized from the master microservice to achieve backup and expansion of the master microservice. The microservice as a slave microservice will continuously receive message events synchronized from the master microservice and process them according to its own business logic. These processes may include data updates, state changes, risk control triggers, etc. At the same time, the slave microservice will also maintain synchronization with the master microservice to ensure that it can seamlessly take over the work of the master microservice when needed.

[0094] In a feasible implementation manner, step S10 may include step A30:

[0095] Step A30, according to the business processing unit in the main microservice, performs a preset business logic operation on the instruction information to obtain a calculation result, and when an abnormality is detected in the main microservice, the business processing unit in the slave microservice performs a preset business logic operation on the instruction information to obtain a calculation result.

[0096] First, when the system receives the instruction information, it will send it to the business processing unit in the main microservice. The business processing unit will process the instruction information according to the preset business logic operation to obtain the operation result. However, in the actual operation process, the main microservice may be abnormal due to various reasons, such as network failure, hardware failure or program error. At this time, if the system continues to rely on the main microservice for processing, it may cause serious consequences such as business interruption or data loss. In order to avoid this situation, this embodiment adopts a mechanism of using the slave microservice as a backup. When the master-slave arbitration module detects that the main microservice is abnormal, it will immediately switch to the slave microservice, and the business processing unit in the slave microservice will perform the same preset business logic operation on the instruction information. Since the slave microservice keeps data synchronization and state consistency with the main microservice, it can ensure the continuity of the business and the integrity of the data during the switching process.

[0097] Specifically, the master-slave arbitration module will use the heartbeat detection mechanism to detect the running status of the master microservice in real time. Once an abnormality is found, the system will immediately trigger the switching logic and transfer the processing task of the instruction information to the slave microservice. After receiving the instruction information, the slave microservice will process it according to the preset business logic operation and return the operation result to the system.

[0098] In this embodiment, after starting the microservice, the microservice immediately enters the master-slave state listening stage, and the master-slave state of each microservice in the cluster is updated in real time through the master-slave arbitration module to ensure transparent management and efficient scheduling of the service cluster. By setting the microservice as a slave microservice, and combining the master-slave service architecture and reliable multicast bus technology, the present invention realizes multi-active high availability of the system. Even if the master microservice fails or is abnormal, the slave microservice can quickly take over the work to ensure the continuous operation of the system and the integrity of the data.

[0099] In a feasible implementation manner, step A10 may include step B10:

[0100] Step B10, if there is no master microservice among the multiple microservices, the master microservice among the multiple microservices is determined according to the master-slave arbitration module, and the business processing unit in the master microservice performs a preset business logic operation on the instruction information to obtain a calculation result.

[0101] If there is no master microservice in the current microservice architecture, the current microservice needs to assume the responsibility of the master microservice. The microservice will register through the master-slave arbitration module and apply to become the new master microservice. At the same time, the microservice will perform a series of initialization operations, such as loading configurations, starting necessary service components, etc., to prepare to start event processing. After becoming the master microservice, the microservice will begin to listen to and process business events from clients or other services. These events will be processed step by step through a series of business processing units in the serial pipeline, and each business processing unit is responsible for completing specific business logic. During the processing process, the microservice will use the business processing unit concurrency model and reliable multicast communication technology to achieve efficient, low-latency, and highly reliable business processing.

[0102] Furthermore, microservices will also use the sandbox mechanism of Docker containers and the kernel penetration technology of high-performance network cards to ensure the mutual isolation of different microservice operating environments and low-latency, high-throughput network communication across hosts.

[0103] In this embodiment, if the main service is missing in the microservice cluster, the current microservice will quickly take over the main service role and immediately start event processing by registering, initializing and loading necessary configurations. In this process, the microservice uses a serial pipeline to decompose the business logic into a series of business processing units for step-by-step processing. Each business processing unit performs its own duties, and through concurrent models and reliable multicast communication technology, high efficiency, low latency and high reliability of business processing are achieved. This mechanism not only enhances the flexibility and scalability of the system, but also ensures the high availability and continuity of business processing in the cluster, providing a solid guarantee for the stable operation of the distributed system.

[0104] In a feasible implementation manner, step A10 may include steps C10 to C20:

[0105] Step C10, when it is detected that at least one microservice has been successfully started, determining whether the microservice is in a preset replay mode;

[0106] It should be noted that replay mode is a system operation mode used to re-execute or "replay" a previously processed message sequence. This is usually used for debugging, data recovery, or to ensure the accuracy of message processing.

[0107] When the system detects that at least one microservice has been successfully started, it first checks whether the microservice is currently in replay mode. This judgment is usually based on system configuration or specific event triggers.

[0108] Step C20, if it is the replay mode, read the preset target sequence number of the maximum consumed message, set the preset starting sequence number of the replay message to the target sequence number plus one, and start the replay.

[0109] It should be noted that in the message system, each message has a unique sequence number to identify its processing order. The target sequence number of the largest consumed message refers to the largest sequence number that the system has successfully processed and confirmed so far. In replay mode, the system will reprocess messages starting from this sequence number. Usually, this sequence number follows the target sequence number of the largest consumed message to ensure that no message is processed repeatedly. The replay end event is a specific event used to indicate that the replay process has been completed and the system can return to normal message processing mode.

[0110] If the system is in replay mode, it first reads the preset target sequence number of the largest consumed message. The system then adds one to this sequence number as the starting sequence number for the replay message. This is done to ensure that the replay process does not repeat any messages that have already been successfully processed. Once the starting sequence number of the replay message is set, the system will reprocess the message from this sequence number. The replay process usually involves resending the message to the corresponding processing unit and simulating the previous processing steps to ensure that all messages are processed correctly. If the system is not in replay mode, it will continue to execute the step of listening to the master and slave status of each microservice. When the system completes the replay process and receives the replay end event, it will return to normal message processing mode. At this time, the system will start listening to the master and slave status of each microservice again to ensure that the system can continue to run stably and process new messages.

[0111] For example, refer to Figure 6When the application (microservice) starts, the application is initialized and it is determined whether it is in replay mode. If not, the master-slave status of each application in the cluster is directly monitored. If yes, the sequence number (Seq) of the largest local consumed message is read, and the starting sequence number of the replay message is set to the sequence number plus one, and then the replay process is started. Listen for the replay end event. Once the event is received, the business processing unit 3 (business processing unit 3, here is Figure 5 Taking the business processing unit as an example, which is generally the last business processing unit in the serial pipeline), a replay end mark is set in the business processing unit 3, and then the step of listening to the master-slave status of each application in the cluster is executed to determine whether a master service already exists; if so, the current application is converted to a pre-slave service (preparatory slave service), and a synchronization request is sent to the master service of the cluster to synchronize the missing message of the slave service, and the synchronization end event is listened for. Once the event is received, the synchronization end mark is set in the business processing unit 3; if not, an application is made to the master-slave arbitration center to become the master service. After the application, it is determined whether the current service has been arbitrated as the master service. If so, the current application is converted to the master service. If not, the step of listening to the master-slave status of each application in the cluster is returned; finally, the current application resumes normal event processing according to the arbitration result and the synchronization status.

[0112] In the method, the replay process includes setting a replay start sequence number and replaying the message according to the sequence number. Listening for the replay end event includes setting a replay end mark in a specific business processing unit to indicate the end of the replay process. Listening for the synchronization end event includes setting a synchronization end mark in a specific business processing unit to indicate the end of the synchronization process. The synchronization request includes synchronizing the missing messages from the service to ensure the data integrity of the slave service.

[0113] Through this embodiment, the system can flexibly switch between different operating modes to ensure the accuracy of message processing and system stability. In non-replay mode, the system continuously listens to the master-slave status of each microservice to maintain the normal operation of the cluster. Once in replay mode, the system accurately locates and reprocesses the message sequence to avoid repeated processing while ensuring that all messages are executed correctly. After the replay is completed, the system seamlessly switches back to normal mode and continues to listen to the microservice status to ensure the continuity and efficiency of message processing. This mechanism not only improves the system's fault tolerance and data recovery efficiency, but also ensures the consistency and accuracy of message processing, providing strong support for stable operation in complex business scenarios.

[0114] For example, refer to Figures 7 to 10 , which are UML (Unified Model Language) diagrams of the pipeline class, basic mail class, business processing unit class, and bus adapter class respectively.

[0115] The pipeline class includes the parallel pipeline class and the serial pipeline class. The parallel pipeline class provides functions such as adding business processing units, input, initialization, start, stop, etc. to control the operation of the pipeline. Parallel pipeline and ~parallel pipeline are constructors and destructors respectively. The serial pipeline class is similar to the parallel pipeline class, but focuses on serial processing. Serial pipeline and ~serial pipeline are constructors and destructors respectively. Provides functions such as adding business processing units, input, initialization, start, stop, etc.

[0116] The replay mail class provides a constructor and a destructor. The functions "Whether to start replay" and "Whether to end replay" are used to check the replay status. The election mail class provides a constructor and a destructor. The debug string function is used to output debug information. The "Whether master state" function checks whether it is the master state. The "Whether slave state" function checks whether it is the slave state. Provides a constructor and a destructor. The "Whether to end replay" and "Whether to start replay" functions are used to check the state after replay. The basic mail class contains three member variables: sequence number, name, and type. Provides conversion, hash, name, type and other functions. The keep-alive mail class provides a constructor and a destructor. The debug string function is used to output debug information. The new order request mail class and the execution report mail class provide a constructor and a destructor. The metadata function is used to obtain the metadata of the mail. The debug string function is used to output debug information.

[0117] The business processing unit implementation class connects the business processing unit class with the business processing unit delivery class. The business processing unit class provides functions such as setting operators, connection functions, initialization, start, and stop to configure and control the business processing unit. The constructor and destructor are used to create and destroy objects. The delivery mail function is used to process mails. The business processing unit implementation class provides the same functions as the business processing unit class. The constructor and destructor are used to create and destroy objects. The delivery mail function is used to process mails.

[0118] The bus adapter class includes the bus transmitter 2 class, the bus listener class, the bus adapter implementation class, and the bus adapter class. The bus transmitter 2 class contains constructors and destructors for creating and destroying objects. The functions of setting the end of the replay block and setting the end of the post-replay block are used to configure the end point of the message replay. The send message function is used to send messages. The bus listener class provides constructors and destructors. It contains the switch to master state and switch to slave state functions for processing role changes. The start replay, end replay, start after replay, and end after replay functions are used to control the replay process. The execute filter and message receiving functions are used for message processing. The bus adapter implementation class contains two member variables, the bus instance and the service provider interface instance. Constructors and destructors are provided, as well as control functions such as initialization, start, and stop. Set the bus service provider interface and get bus transmitter 2 for configuring and accessing bus services. Set the filter sequence, set the end of the replay block, and set the end of the post-replay block functions are used to set message processing parameters. The send message function is used to send messages. The switch to master state and switch to slave state functions handle role changes. The start replay, end replay, after start replay and after end replay functions control the replay process. The execution filter and message receiving functions are used for message processing.

[0119] It should be noted that, under the condition that the technology is feasible and the logic is clear, the above embodiments can be combined in pairs or in multiple combinations.

[0120] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the cloud-native ultra-fast trading method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0121] The present application provides a cloud-native-based ultra-fast trading device, and the cloud-native-based ultra-fast trading device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the cloud-native-based ultra-fast trading method in the above-mentioned embodiment one.

[0122] Reference below Fig.11, which shows a schematic diagram of the structure of a cloud-native ultra-fast trading device suitable for implementing the embodiment of the present application. The cloud-native ultra-fast trading device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.11 The cloud-native-based ultra-fast trading device shown is merely an example and should not bring any limitations to the functions and scope of use of the embodiments of the present application.

[0123] like Fig.11 As shown, the cloud-native ultra-fast trading device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the cloud-native ultra-fast trading device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the cloud-native-based ultra-fast trading device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a cloud-native-based ultra-fast trading device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or provided alternatively.

[0124] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0125] The cloud-native-based ultra-fast trading device provided by the present application adopts the cloud-native-based ultra-fast trading method in the above-mentioned embodiment, which can solve the technical problem of low efficiency of the ultra-fast trading system. Compared with the prior art, the beneficial effects of the cloud-native-based ultra-fast trading device provided by the present application are the same as the beneficial effects of the cloud-native-based ultra-fast trading method provided in the above-mentioned embodiment, and the other technical features in the cloud-native-based ultra-fast trading device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0126] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0127] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0128] The present application provides a medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the cloud-native-based ultra-fast trading method in the above-mentioned embodiment.

[0129] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0130] The above-mentioned computer-readable storage medium may be included in the cloud-native ultra-fast trading device; or it may exist independently without being assembled into the cloud-native ultra-fast trading device.

[0131] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the cloud-native ultra-fast trading device, the cloud-native ultra-fast trading device:

[0132] Receive external command information through a reliable multicast bus and send the command information to the business processing unit;

[0133] The business processing unit receives the instruction information sent by the reliable multicast bus, performs a preset business logic operation on the instruction information, obtains the operation result, and transmits the operation result to the next business processing unit of the same serial pipeline through a preset lock-free message queue, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation;

[0134] After all business processing units have completed the calculation, the calculated instruction information is obtained and returned to the reliable multicast bus. The reliable multicast bus receives the calculated instruction information and outputs the calculated instruction information.

[0135] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0136] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0137] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0138] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned cloud-native-based ultra-fast trading method, and can solve the technical problem of low efficiency of the ultra-fast trading system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the cloud-native-based ultra-fast trading method provided in the above-mentioned embodiment, and will not be repeated here.

[0139] The present application also provides a product, which is a computer program product, including a computer program, which implements the steps of the above-mentioned cloud-native based ultra-fast trading method when executed by a processor.

[0140] The computer program product provided in this application can solve the technical problem of low efficiency of the ultra-fast trading system. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the cloud-native ultra-fast trading method provided in the above embodiment, which will not be repeated here.

[0141] The above are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A cloud-native high-speed trading system, characterized in that: The cloud-native-based ultra-fast trading system includes a reliable multicast bus encapsulated in a Docker container, and at least one serial pipeline arranged in a microservice architecture, wherein a plurality of business processing units are arranged in any of the serial pipelines, and the plurality of business processing units are sequentially connected in series; The reliable multicast bus is used to receive external instruction information and send the instruction information to the service processing unit; The business processing unit is used to receive the instruction information sent by the reliable multicast bus, perform a preset business logic operation on the instruction information, obtain an operation result, and transmit the operation result to the next business processing unit of the same serial pipeline through a preset lock-free message queue. After all business processing units have completed the operation, the calculated instruction information is obtained, and the calculated instruction information is fed back to the reliable multicast bus, wherein the business processing unit corresponds to the business logic operation one by one, and the business logic operation corresponding to each business processing unit is different; The reliable multicast bus is used to receive the calculated instruction information and output the calculated instruction information.

2. The cloud-native high-speed trading system according to claim 1, characterized in that: The cloud-native-based ultra-fast trading system also includes a master-slave arbitration module, the microservice architecture includes multiple microservices, and the multiple microservices are connected to the master-slave arbitration module, and the serial pipelines in the multiple microservices are connected to the reliable multicast bus.

3. A cloud-native high-speed trading method, characterized in that: Applied to the cloud-native-based ultra-fast trading system as described in any one of claims 1 to 2, the cloud-native-based ultra-fast trading method comprises: Receiving external instruction information through a reliable multicast bus in the cloud-native-based extreme-speed trading system; The business processing unit in the cloud-native ultra-fast trading system performs a preset business logic operation on the instruction information to obtain a calculation result, and transmits the calculation result to the next business processing unit belonging to the same serial pipeline through a preset lock-free message queue, wherein the business processing unit corresponds to the business logic operation one by one, and each business processing unit corresponds to a different business logic operation; After all the service processing units have completed the operation, the operated instruction information is obtained, and the operated instruction information is output according to the reliable multicast bus.

4. The cloud-native-based ultra-fast trading method according to claim 3, characterized in that: The step of executing a preset business logic operation on the instruction information by the business processing unit in the cloud-native-based extreme-speed trading system includes: Each business processing unit in the cloud-native ultra-fast trading system is associated with a scheduling thread, which calls the preset business logic operation according to the scheduling thread to perform logical operations on the instruction information to obtain the operation results, wherein each scheduling thread is configured with a CPU affinity setting and is bound to the preset CPU NUMA node.

5. The cloud-native-based ultra-fast trading method according to claim 3, characterized in that: The cloud-native-based ultra-fast trading method also includes: Monitor whether there is a main microservice among multiple microservices in the microservice architecture; If the master microservice exists among the multiple microservices, determine a slave microservice among other microservices except the master microservice among the multiple microservices, wherein the other microservice sends a service request to the master-slave arbitration module to become a slave microservice, and after receiving a successful response from the master-slave arbitration module to the service request, sends a synchronization message request to the master microservice, and if the other microservice receives a synchronization message returned by the master microservice, determines that the other microservice is a slave microservice; The step of performing a preset business logic operation on the instruction information by the business processing unit in the cloud-native-based extreme-speed trading system to obtain the operation result includes: The business processing unit in the main microservice performs a preset business logic operation on the instruction information to obtain a calculation result, and when an abnormality is detected in the main microservice, the business processing unit in the slave microservice performs a preset business logic operation on the instruction information to obtain a calculation result.

6. The cloud-native-based ultra-fast trading method according to claim 5, characterized in that: The step of monitoring whether there is a main microservice in the multiple microservices of the microservice architecture includes: If the master microservice does not exist in the multiple microservices, the master microservice in the multiple microservices is determined according to the master-slave arbitration module, and a preset business logic operation is performed on the instruction information according to the business processing unit in the master microservice to obtain a calculation result.

7. The cloud-native-based ultra-fast trading method according to claim 5, characterized in that: The step of monitoring whether there is a main microservice in the multiple microservices of the microservice architecture includes: When it is detected that at least one microservice is successfully started, determining whether the microservice is in a preset replay mode; If it is a replay mode, the target sequence number of the preset maximum consumed message is read, and the starting sequence number of the preset replay message is set to the target sequence number plus one, and the replay is started.

8. A cloud-native high-speed trading device, characterized in that: The cloud-native-based ultra-fast trading device includes: a cloud-native-based ultra-fast trading system as described in any one of claims 1 to 2, a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the cloud-native-based ultra-fast trading method as described in any one of claims 3 to 7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the cloud-native based ultra-fast trading method as described in any one of claims 3 to 7.

10. A computer program product, characterized in that The computer program product comprises a computer program, which, when executed by a processor, implements the steps of the cloud-native based ultra-fast trading method as claimed in any one of claims 3 to 7.

Images