Cloud-native ultra-fast transaction system, method, device, medium and product

Abstract

The application discloses a cloud-native ultrafast transaction system, method, device, medium and product, relates to the technical field of computer network communication, and the system comprises a reliable multicast bus encapsulated in a Docker container, at least one serial assembly line arranged in a micro-service architecture, and a plurality of service processing units arranged in any serial assembly line. The reliable multicast bus is used for receiving external instruction information and transmitting the instruction information to the service processing units. The service processing units are used for performing preset service logic operation on the instruction information, obtaining operation results, and transmitting the operation results to the next service processing unit of the same serial assembly line through a lock-free message queue. After all the service processing units complete operation, the already-operated instruction information is obtained, and the already-operated instruction information is fed back to the reliable multicast bus. The reliable multicast bus is used for receiving and outputting the already-operated instruction information. The application improves the research and development efficiency of the ultrafast transaction system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer network communication, in particular to a cloud-native lightning transaction system, method, device, medium and product. BACKGROUND

[0002] When building a complex transaction business system, the order, position, risk control, routing, etc. are usually divided into mature modules according to the field boundary, so as to realize the processing of multiple order events, multiple securities entities, multiple risk rules and multiple order routing. The current mainstream lightning transaction technology scheme usually integrates these modules in a business processing unit to realize low latency, high reliability and data strong consistency lightning transaction. However, since all business functions are integrated into a business processing unit, the system constructed by such a scheme has high complexity, low throughput and great difficulty in function expansion. These factors interact with each other, and finally result in low efficiency of lightning transaction system development. SUMMARY

[0003] The main purpose of the present application is to provide a cloud-native lightning transaction system, method, device, medium and product, which aims to solve the technical problem of low efficiency of lightning transaction system development.

[0004] To achieve the above purpose, the present application provides a cloud-native lightning transaction system, which comprises a reliable multicast bus encapsulated in a Docker container, and at least one serial flow line arranged in a micro-service architecture. A plurality of business processing units are arranged in any serial flow line, and the plurality of business processing units are connected in series.

[0005] The reliable multicast bus is used for receiving external instruction information and sending the instruction information to the business processing unit.

[0006] The business processing unit is used for receiving the instruction information sent by the reliable multicast bus, executing a preset business logic operation on the instruction information to obtain an operation result, and transmitting the operation result to the next business processing unit of the same serial flow line through a preset lock-free message queue. After all the business processing units are operated, the operated instruction information is obtained and fed back to the reliable multicast bus. 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.

[0007] The reliable multicast bus is used for receiving the operated instruction information and outputting the operated instruction information.

[0008] In one embodiment, the cloud-native high-speed 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, a 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, obtains 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. Among them, the business processing unit corresponds one-to-one with the business logic operation, and each business processing unit corresponds to a different business logic operation;

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

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

[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. Among them, each scheduling thread is configured with CPU affinity settings and bound to the preset CPU NUMA node.

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

[0016] Monitor whether a master microservice exists among multiple microservices in a microservice architecture;

[0017] If there is a master microservice among the multiple microservices, determine a slave microservice from 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. 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 instruction information by 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. 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 primary microservice exists among multiple microservices in the 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 the operation result.

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

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

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

[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 runnable on the processor, and 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. A computer program is stored on the computer-readable storage medium. When the computer program is executed by the 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. 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, ultra-fast 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, shielding the impact of the complexity and diversity of the host environment on the version compatibility of the reliable multicast bus library, expanding the scope of application of the reliable multicast bus, and improving the compatibility and release efficiency of multiple operating system versions of microservices. Native support for low-latency and highly reliable multicast communication in the Docker virtual environment allows developers to quickly implement reliable multicast bus integration and complete the construction of a low-latency and highly reliable 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 the preset business logic operation on the instruction information, obtain the operation result, and transmit the operation result to the next business processing unit in the same serial pipeline through the 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. Relying on a multicast bus, where business processing units correspond one-to-one to business logic operations, and each business processing unit corresponds to different business logic operations, the business processing unit concurrency model is used to achieve flexible decoupling of multiple business modules. 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. Circular message queues are used between each business processing unit on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, orderly, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, completing the connection between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy orderly, guaranteed arrival, and traceable capabilities of reliable multicast bus message transmission, it is possible to achieve distributed pipeline microservices and reliable multi-activity of microservices at a low cost. Developers use assembly-style, lock-free programming and focus on implementing the business logic of each business processing unit. They can complete multi-active microservice development for transaction event processing and cross-process data transmission at the ten-microsecond level, thereby avoiding the heavy technical problems of solving high concurrency congestion, data communication reliability, memory data consistency, and service high availability in the ultra-fast trading system, and 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 following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

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

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

[0034] Figure 3 This is the architectural design diagram of the first embodiment of the cloud-native high-speed trading system of this application;

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

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

[0037] Figure 6 This is a flowchart 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 for the cloud-native high-speed trading system for this application;

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

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

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

[0043] The purpose, features and advantages of this application will be further explained 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 merely used to explain the technical solutions of the present application and are not intended 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 a reliable multicast bus and microservices architecture supports complex over-the-counter derivatives trading business. When it comes to complex transactions requiring support for multiple business modules such as contract trading, capital and securities control, pre-risk control, over-the-counter matching, and hedging transactions, there are usually two implementation methods:

[0047] (1) Figure 1 As shown, an application (microservice) is implemented for each business module. 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 the Linux (an operating system) operating system and kernel bypass. However, this method has the technical disadvantages of lengthy transaction link networks and large transaction delays.

[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 approach has the technical disadvantages of complex logic of a single business processing unit, difficulty in function expansion, and low service throughput.

[0049] In response to the above technical shortcomings, this embodiment aims to optimize the existing reliable multicast bus technology by integrating Docker (a container engine) containers and business processing unit concurrency models 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, ensuring isolation and consistency of different application environments, and optimizing message forwarding and multicast communication. Second, by creating independent business processing units, each business processing unit is responsible for a single business logic, achieving decoupling of business modules and efficient concurrent processing. Third, an independent scheduling thread is allocated to each business processing unit, CPU (central processing unit) affinity is set, and it is bound to the CPU's NUMA (Non-Uniform Memory Access) core to reduce thread switching overhead, increase CPU memory access speed, and achieve business processing at the ten-microsecond level. Finally, the business processing units are registered to the serial pipeline in dependency order, and nanosecond data interaction is achieved through lock-free queues, maintaining business function integrity, reducing processing latency, and improving system throughput. Furthermore, the integrated reliable multicast bus, based on the UDP (User Datagram Protocol), integrates mechanisms such as message confirmation / retransmission, forward error correction, and congestion control, ensuring stable, efficient, and reliable end-to-end message transmission. Furthermore, the introduction of core penetration technology reduces data copying, lowers CPU utilization and latency, and enables low-latency, high-throughput communication across hosts by processing network packets in user space. These optimization measures collectively enhance the R&D efficiency and operational performance of the ultra-fast trading system.

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

[0051] In this embodiment, the cloud-native high-speed trading system includes a reliable multicast bus encapsulated in a Docker container and at least one serial pipeline set in a microservice architecture. Multiple business processing units are set in each serial pipeline, and the multiple business processing units are connected in series in sequence.

[0052] Reliable multicast bus, used to receive external instruction information and send the instruction information to the business processing unit;

[0053] The business processing unit is used to receive 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 operation, the calculated instruction information is obtained and the calculated instruction information is fed back to the reliable multicast bus. 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 native UDP multicast communication protocol. The reliable multicast bus is provided with a message confirmation / retransmission mechanism, forward error correction technology, congestion control algorithm, master / slave message sequencing mechanism, and multi-copy persistent traceability mechanism. The reliable multicast bus can realize stable, efficient, and reliable transmission of cross-process end-to-end messages, use the message confirmation / retransmission mechanism to ensure the stability and delivery of message transmission, use forward error correction technology to reduce the number of message retransmissions, and adjust the sending rate through the congestion control algorithm. At the same time, combined with the master / slave message sequencing mechanism and multi-copy persistent traceability mechanism, the traceability of data and the reliable and orderly transmission of multiple copies of messages are realized.

[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 mutual 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] Serial pipelining can be a serial pipeline processing mechanism that includes a registration mechanism for registering and managing business processing units (BPUs) and a pipeline processing mechanism for controlling message transmission between BPUs. Serial pipelining ensures that BPUs register and transmit messages according to a pre-defined dependency order, enabling lock-free, low-latency, and parallel execution throughout the entire BPU processing process.

[0058] A business processing unit (BPU) can independently process the logic of a single business module. It includes independent data cache space, a lock-free message queue, and independent scheduling threads and thread affinity. Furthermore, scheduling threads can be bound to specific CPU NUMA processing cores to increase processing efficiency. BPUs enable flexible decoupling of multiple business modules, with each BPU handling only the logical operations of a single business module.

[0059] In this embodiment, when instruction information is sent from the outside (or other internal reliable multicast buses) and 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 results to the next business processing unit through a lock-free message queue. When all business processing units have completed 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 for the next step of processing.

[0060] This embodiment provides a cloud-native, ultra-fast 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 utilizing Docker container technology, the reliable multicast bus library is encapsulated, shielding the impact of the complex and diverse host environment on the version compatibility of the reliable multicast bus library, expanding the application scope of the reliable multicast bus, and improving the compatibility and release efficiency of multiple operating system versions of microservices. Native support for low-latency, highly reliable multicast communication in the Docker virtual environment allows developers to quickly implement reliable multicast bus integration and complete the construction of a low-latency, highly reliable architecture, simply by being 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 the preset business logic operation on the instruction information, obtain the operation result, and transmit the operation result to the next business processing unit in the same serial pipeline through the 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. Relying on a multicast bus, where business processing units correspond one-to-one to business logic operations, and each business processing unit corresponds to different business logic operations, the business processing unit concurrency model is used to achieve flexible decoupling of multiple business modules. 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. Circular message queues are used between each business processing unit on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, orderly, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, completing the connection between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy orderly, guaranteed arrival, and traceable capabilities of reliable multicast bus message transmission, it is possible to achieve distributed pipeline microservices and reliable multi-activity of microservices at a low cost. Developers use assembly-style, lock-free programming and focus on implementing the business logic of each business processing unit. They can complete multi-active microservice development for transaction event processing and cross-process data transmission at the ten-microsecond level, thereby avoiding the heavy technical problems of solving high concurrency congestion, data communication reliability, memory data consistency, and service high availability in the ultra-fast trading system, and can effectively improve the efficiency of the ultra-fast trading system.

[0061] In one feasible implementation, the cloud-native high-speed trading system further 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;

[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 master-slave arbitration, multiple microservices within the cluster achieve a single-master, multiple-slave microservice state. The master-slave arbitration module contains cluster configuration information and message sequencing rules. It distributes these configuration information and sequencing rules to the cluster's master and slave microservices. The master microservice queues and sequences messages received from the multicast bus, and then synchronizes the queued and sequenced message sequence with the slave microservices, ensuring reliable and orderly message transmission and synchronization across multiple replicas within the service cluster.

[0063] A microservices architecture is a distributed service framework consisting of multiple microservices. Each microservice is an independent, independently deployable and scalable business unit responsible for handling specific business logic. Microservices in a microservices architecture are divided into master services and slave services. The master service coordinates and manages other services in the cluster, handling key business logic and decision-making. The slave service is responsible for executing tasks assigned by the master service, such as data synchronization and status updates. When necessary, the slave service can serve as a backup for the master service, taking over its responsibilities if the master service fails.

[0064] First, a microservice is launched through a Docker container. This microservice monitors whether a master microservice exists among the multiple microservices in the microservice architecture. If not, the microservice communicates with the master-slave arbitration module to apply to become the master microservice. It then receives instructions from the reliable multicast bus via the business processing units in the serial pipeline and begins processing. Each business processing unit passes the processing results to the next business processing unit in the pipeline via a lock-free message queue until all business logic is complete. Once all business processing units have completed processing, the processed instructions are sent back to the microservice via the reliable multicast bus, which then feeds back to external systems or other microservices.

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

[0066] For example, refer to Figure 3The system processes information using a master application (i.e., master microservice) and slave applications (i.e., slave microservices). These applications are connected and interact with each other via serial pipelines and a reliable multicast bus. The master application, as the core node of the system, is responsible for handling critical business logic. Data flows first enter the master application's serial pipeline, which consists of Business Processing Units 1, 2, and 3 arranged in sequence. Each unit performs specific business operations and passes the results to the next unit. System communication relies on a reliable multicast bus, which ensures stable and reliable message transmission between the master and slave application nodes. This mechanism is crucial for maintaining data consistency and system state synchronization. To optimize network communication, the system utilizes 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 increasing 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 the master and slave applications. This ensures that only one application is active at any given time, performing critical operations as the primary application, while the other applications serve as slaves on standby. If the primary application fails, the master-slave arbitration center quickly elects a new primary application, ensuring system continuity and high availability. Under normal circumstances, the slave application serves as a backup, listening to status updates from the master-slave arbitration center and preparing to take over the primary application's responsibilities when needed. Once data has been processed and synchronized in the primary application, the slave application receives this data, ensuring seamless takeover in the event of a primary application failure.

[0067] This embodiment achieves efficient and reliable service coordination and data processing by introducing a master-slave arbitration module and a microservices architecture. The master-slave arbitration module ensures reliable and orderly message transmission and synchronization across multiple replicas in the service cluster, avoiding data inconsistencies and conflicts. The microservices architecture improves the system's flexibility and maintainability by splitting business logic into multiple independent, deployable, and scalable microservices. Furthermore, microservices monitor the presence of a master microservice and intelligently apply to become either a master or a slave, enabling automatic load balancing and failover of services. When a microservice functions as a master microservice, it efficiently processes business logic operations and promptly feeds back processing results to external systems or other microservices. When a microservice functions as a slave microservice, it promptly synchronizes its status with the master microservice, ensuring service consistency and reliability. This design not only improves the system's processing speed and responsiveness, but also enhances its stability and availability.

[0068] Based on Example 1 of the present application, in Example 2 of the present application, the same or similar contents as those in the above Example 1 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 execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or terminal system capable of implementing the above functions. The following uses the cloud-native high-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 high-speed trading method, which is applied to a cloud-native-based high-speed trading system. The cloud-native-based high-speed 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. Figure 4 , Figure 4 This is a flow chart of Example 2 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 via a reliable multicast bus in the cloud-native high-speed 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 external command information via a reliable multicast bus. This step involves network communication, where the reliable multicast bus utilizes its built-in communication protocol to ensure that command information reliably reaches the system even under unstable network conditions. After receiving the command information, the reliable multicast bus passes it to the business processing units in the serial pipeline.

[0074] In step S20, the business processing unit in the cloud-native high-speed 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. 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] A microservices architecture consists of numerous serial pipelines, each containing multiple business processing units (BPUs). A reliable multicast bus selects a target serial pipeline according to pre-set program settings. The BPUs in this target serial pipeline then sequentially transmit instructions to each BPU registered in the target serial pipeline, based on the dependencies between them. Each BPU performs specific business logic operations on the instructions. This step involves specific data processing, with the BPU performing calculations or transformations based on pre-set rules to generate the results.

[0077] Step S30 : After all the service processing units have completed the operations, the calculated instruction information is obtained and the calculated instruction information is outputted via 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, 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 external systems or other reliable multicast buses for further processing. This step may involve transmitting 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 into the system via the reliable multicast bus, it first enters the first business processing unit, business processing unit 1. This unit performs a series of operations, such as validation and preprocessing, to produce message-1-2-3. Message-1-2-3 is then passed to the next stage. The message passes through multiple business processing units in a serial pipeline sequence, each completing its specific task before passing it to the next: business processing unit 2, which produces message-1-2, and business processing unit 3, which produces 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. Simultaneously, the system interacts with the database for message-1. This may mean storing the data contained in the message in an in-memory database or retrieving additional data from the in-memory database to complete the message processing.

[0081] This embodiment provides a cloud-native, ultra-fast 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 utilizing Docker container technology, the reliable multicast bus library is encapsulated, shielding the impact of the complex and diverse host environment on the version compatibility of the reliable multicast bus library, expanding the application scope of the reliable multicast bus, and improving the compatibility and release efficiency of multiple operating system versions of microservices. Native support for low-latency, highly reliable multicast communication in the Docker virtual environment allows developers to quickly implement reliable multicast bus integration and complete the construction of a low-latency, highly reliable architecture, simply by being 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 the preset business logic operation on the instruction information, obtain the operation result, and transmit the operation result to the next business processing unit in the same serial pipeline through the 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. Relying on a multicast bus, where business processing units correspond one-to-one to business logic operations, and each business processing unit corresponds to different business logic operations, the business processing unit concurrency model is used to achieve flexible decoupling of multiple business modules. 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. Circular message queues are used between each business processing unit on the serial pipeline to achieve non-competitive data interaction, thereby achieving decoupling, orderly, sticky core, and efficient operation of each business processing unit on the entire business processing serial pipeline, completing the connection between the production end and the consumer end. Combining the business processing unit concurrency model and the multi-copy orderly, guaranteed arrival, and traceable capabilities of reliable multicast bus message transmission, it is possible to achieve distributed pipeline microservices and reliable multi-activity of microservices at a low cost. Developers use assembly-style, lock-free programming and focus on implementing the business logic of each business processing unit. They can complete multi-active microservice development for transaction event processing and cross-process data transmission at the ten-microsecond level, thereby avoiding the heavy technical problems of solving high concurrency congestion, data communication reliability, memory data consistency, and service high availability in the ultra-fast trading system, and 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-based ultra-fast transaction system is associated with a scheduling thread, and the scheduling thread calls the preset business logic operation to perform logical operation on the instruction information to obtain an operation result, wherein each scheduling thread is configured with a CPU affinity setting and is bound to a preset CPU NUMA node.

[0084] It should be noted that the scheduling thread is a thread for managing and scheduling the work of the business processing unit, ensuring that the business logic can be executed in the expected order and priority. The CPU affinity setting is a technology for binding threads or processes to specific CPU cores to reduce the overhead of thread migration and improve CPU cache hit rate, thereby improving performance. The NUMA node is a memory and processor combination unit in the Non-Uniform Memory Access (NUMA) architecture, and the processors in each NUMA node access local memory faster than accessing memory in other nodes.

[0085] First, in the ultra-fast transaction 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 instruction information according to system requirements. Instruction information can be a transaction request, market data update, or other business events that need to be processed by the system. In order to improve system performance, each scheduling thread is configured with a CPU affinity setting. When the system receives instruction information, the corresponding scheduling thread will perform logical operation on the instruction information according to the preset business logic operation. During this process, the scheduling thread will fully utilize the performance advantages of the CPU and NUMA node it is bound to, ensuring that the logical operation can be completed quickly and accurately. Finally, the scheduling thread returns the operation result to the system, which then performs subsequent operations based on the operation result, such as updating transaction status, sending transaction confirmation, etc.

[0086] This embodiment reduces the overhead of thread context switching by setting independent scheduling threads and thread affinity, improves the hit rate of CPU cache, binds the scheduling thread to the NUMA processing core of the specified CPU, and combines the NUMA cache acceleration mechanism to improve the speed of CPU accessing memory, achieving exclusive operation of the scheduling thread on the CPU and ten-microsecond-level 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 content as the above first or second embodiment can refer to the above introduction, and will not be described in detail. The cloud-based ultra-fast transaction method further includes steps A10-A20:

[0088] Step A10, monitoring whether there is a master microservice in the plurality of microservices in the microservice architecture;

[0089] It's important to note that monitoring refers to a system or program actively monitoring specific events or state changes. In this context, monitoring refers to monitoring the master-slave status of each microservice in a cluster. In a distributed microservices architecture, multiple microservices exist, each with a master-slave relationship. Typically, a master microservice handles critical tasks, while slave microservices may handle backup or auxiliary tasks. A master microservice is the node in a service cluster responsible for processing primary business logic or providing services, and therefore requires higher stability and reliability.

[0090] After starting a microservice in a microservice architecture, the microservice will first enter the state of monitoring whether there is a master microservice among other microservices. If it cannot monitor whether there is a master microservice, you can query or subscribe to this 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 a master microservice exists among the multiple microservices, a slave microservice is determined from other microservices in the multiple microservices except the master microservice, wherein the other microservice sends a service request to the master-slave arbitration module to become a slave microservice. After receiving a successful response from the master-slave arbitration module to the service request, the other microservice sends a synchronization message request to the master microservice. 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's important to note that, in contrast to the master microservice, a slave microservice is a service node that follows the master microservice, receiving and processing message events synchronized from the master. In a service cluster model, slave services can provide backup and scalability for the master service, improving system availability and throughput. In a trading system, message events refer to information generated by various business operations that needs to be processed or recorded by the system. These events may include order submissions, position changes, and risk control triggers.

[0093] First, if a microservice learns from the master-slave arbitration center that a master microservice exists in the cluster and is operating normally, it transitions to a standby slave microservice and begins synchronizing message events with the master microservice. These events may include various business data and state changes generated during the microservice's operation. This synchronization process is typically implemented via a reliable multicast bus, ensuring stable and efficient message transmission from the master microservice to the standby slave microservice. After the standby slave microservice completes synchronizing message events with the master microservice, it transitions to a slave microservice. This step is implemented within the service's internal state machine. Once designated as a slave microservice, it begins receiving and processing message events synchronized from the master microservice, enabling backup and scalability of the master microservice. As a slave microservice, it continuously receives message events synchronized from the master microservice and processes them according to its own business logic. This processing may include data updates, state changes, and risk control triggers. Simultaneously, the slave microservice maintains synchronization with the master microservice, ensuring 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] In step A30, the business processing unit in the master microservice performs a preset business logic operation on the instruction information to obtain the operation result. When an abnormality is detected in the master microservice, the business processing unit in the slave microservice performs a preset business logic operation on the instruction information to obtain the operation result.

[0096] First, when the system receives 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, during the actual operation process, the main microservice may have anomalies 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 slave microservice as a backup mechanism. When the master-slave arbitration module detects an anomaly in the main microservice, 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 maintains data synchronization and state consistency with the main microservice, it can ensure business continuity and data integrity during the switching process.

[0097] Specifically, the master-slave arbitration module uses a heartbeat detection mechanism to monitor the operating status of the master microservice in real time. If an anomaly is detected, the system immediately triggers a switchover logic, transferring the processing of the instruction information to the slave microservice. Upon receiving the instruction information, the slave microservice performs the calculations according to the pre-set business logic and returns the results to the system.

[0098] In this embodiment, after starting a microservice, it immediately enters the master-slave state listening phase. The master-slave arbitration module updates the master-slave status of each microservice in the cluster in real time, ensuring transparent management and efficient scheduling of the service cluster. By configuring a microservice as a slave microservice and combining a master-slave service architecture with reliable multicast bus technology, the present invention achieves multi-active and high-availability system. Even if the master microservice fails or experiences an anomaly, the slave microservice can quickly take over, ensuring the continued operation of the system and the integrity of the data.

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

[0100] In 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 a master microservice does not exist in the current microservice architecture, the current microservice will assume the responsibilities of the master microservice. The microservice will register with the master-slave arbitration module, requesting to be the new master microservice. Simultaneously, the microservice will perform a series of initialization operations, such as loading configuration and starting necessary service components, to prepare for event processing. After becoming the master microservice, the microservice will begin listening for and processing business events from clients or other services. These events are processed step by step through a series of business processing units in a serial pipeline, each responsible for implementing specific business logic. During processing, the microservice utilizes 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 utilize 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 between hosts.

[0103] In this embodiment, if the primary service is missing from the microservice cluster, the current microservice will quickly take over the primary service role and immediately begin event processing by registering, initializing, and loading the necessary configuration. During this process, the microservice utilizes 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 functions, and through a concurrency model and reliable multicast communication technology, efficient business processing is achieved with low latency and high reliability. 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 one possible implementation, step A10 can be preceded by steps C10-C20:

[0105] Step C10, upon detecting that there is at least one microservice successfully started, determine whether the microservice is in a preset replay mode;

[0106] It is noted that the replay mode is a system operation mode for re-executing or "replaying" a sequence of messages that have been processed before. This is often used for debugging, data recovery, or ensuring the accuracy of message processing.

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

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

[0109] It is noted that in a message system, each message has a unique sequence number for identifying its processing order. The target sequence number of the maximum consumed message refers to the maximum sequence number that the system has successfully processed and confirmed so far. In the replay mode, the system will start reprocessing messages from this sequence number. Usually, this sequence number is immediately followed by the target sequence number of the maximum consumed message to ensure that no message is processed repeatedly. The replay end event is a specific event indicating that the replay process has been completed, and the system can resume to the normal message processing mode.

[0110] If the system is in the replay mode, it will first read the preset target sequence number of the maximum consumed message. Then, the system adds one to the value of this sequence number as the starting sequence number of the replay message. This is done to ensure that the replay process does not repeat any messages that have been successfully processed. Once the starting sequence number of the replay message is set, the system starts reprocessing messages from this sequence number. The replay process usually involves resending messages to the corresponding processing units and simulating previous processing steps to ensure that all messages are correctly processed. If the system is not in the replay mode, it will continue to perform the step of listening to the master-slave status of each microservice. When the system completes the replay process and receives the replay end event, it will resume to the normal message processing mode. At this time, the system will start listening to the master-slave status of each microservice again to ensure that the system can continue to operate stably and process new messages.

[0111] For example, refer to Figure 6When the application (microservice) starts, it initializes the application and determines whether it is in replay mode. If not, it directly executes the step of monitoring the master-slave status of each application in the cluster; if yes, it reads the sequence number (Seq) of the local largest consumed message and sets the starting sequence number of the replay message to the sequence number plus one, and then starts the replay process. Listen for the replay end event. Once the event is received, it is in business processing unit 3 (business processing unit 3, here 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 marker 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 listen for the synchronization end event. Once the event is received, the synchronization end marker 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 to execute; finally, the current application resumes normal event processing according to the arbitration result and synchronization status.

[0112] In this method, replaying a process includes setting a replay start sequence number and replaying messages according to the sequence number. Listening for a replay end event includes setting a replay end marker in a specific business processing unit to indicate the end of the replay process. Listening for a synchronization end event includes setting a synchronization end marker in a specific business processing unit to indicate the end of the synchronization process. Synchronization requests include synchronizing missing messages from a service to ensure data integrity from the 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 monitors 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, and stop to control the operation of the pipeline. Parallel Pipeline and Parallel Pipeline serve as 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 serve as constructors and destructors, respectively. Functions such as adding business processing units, input, initialization, start, and stop are provided.

[0116] The Replay Message class provides a constructor and destructor. The "Start Replay" and "Stop Replay" functions check the replay status. The Election Message class provides a constructor and destructor. The "Debug String" function outputs debugging information. The "Is Master State" function checks whether the message is in master status. The "Is Slave State" function checks whether the message is in slave status. Both the constructor and destructor are provided. The "After Replay End" and "After Replay Start" functions check the post-replay status. The Base Message class contains three member variables: sequence number, name, and type. Functions such as "Convert," "Hash," "Name," and "Type" are provided. The Keep Alive Message class provides a constructor and destructor. The "Debug String" function outputs debugging information. The New Order Request Message class and the Execution Report Message class provide constructors and destructors. The "Metadata" function retrieves message metadata. The "Debug String" function outputs debugging 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 operator setup, connection functions, initialization, start, and stop functions for configuring and controlling the Business Processing Unit. Constructors and destructors are used to create and destroy objects. Mail delivery functions are used to process mail. The Business Processing Unit Implementation Class provides the same functionality as the Business Processing Unit class. Constructors and destructors are used to create and destroy objects. Mail delivery functions are used to process mail.

[0118] The bus adapter class includes the BusSender2 class, the BusListener class, the BusAdapter implementation class, and the BusAdapter class. The BusSender2 class contains constructors and destructors for object creation and destruction. The SetReplayBlockEnd and SetPostReplayBlockEnd functions configure the end point of message replay. The SendMessage function sends messages. The BusListener class provides constructors and destructors. It also contains the SwitchToMaster and SwitchToSlave functions for handling role changes. The StartReplay, EndReplay, StartAfterReplay, and EndPostReplay functions control the replay process. The ExecuteFilter and MessageReceive functions handle message processing. The BusAdapter implementation class contains two member variables: a bus instance and a service provider interface instance. It provides constructors and destructors, as well as control functions such as initialization, start, and stop. The SetBusServiceProviderInterface and GetBusSender2 functions configure and access bus services. The SetFilterSequence, SetReplayBlockEnd, and SetPostReplayBlockEnd functions set message processing parameters. The SendMessage function sends messages. The SwitchToMaster and SwitchToSlave 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 this application and do not constitute a limitation on the cloud-native ultra-fast trading method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0121] The present application provides a cloud-native-based ultra-fast trading device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed 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 Figure 11, which shows a schematic diagram of the structure of a cloud-native ultra-fast trading device suitable for implementing the embodiments of the present application. The cloud-native ultra-fast trading device in the embodiments 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), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 11 The cloud-native-based ultra-fast transaction device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0123] like Figure 11 As shown, the cloud-native high-speed trading device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the cloud-native high-speed 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, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the cloud-native high-speed trading device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a cloud-native high-speed 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 have instead.

[0124] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising 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 via 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, ultra-fast trading device provided in this application utilizes the cloud-native, ultra-fast trading method described in the aforementioned embodiment to address the technical issue of low efficiency in ultra-fast trading systems. Compared to the prior art, the beneficial effects of the cloud-native, ultra-fast trading device provided in this application are the same as those of the cloud-native, ultra-fast trading method described in the aforementioned embodiment. Other technical features of the cloud-native, ultra-fast trading device are the same as those disclosed in the aforementioned embodiment and are not further elaborated upon here.

[0126] It should be understood that the various parts disclosed in this application can be implemented using 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 embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection 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 this 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 thereof. 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), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction 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), etc., or any suitable combination thereof.

[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 high-speed trading device, the cloud-native high-speed 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 instruction information sent by the reliable multicast bus, performs preset business logic operations on the instruction information, obtains the operation results, and transmits the operation results to the next business processing unit in the same serial pipeline through a preset lock-free message queue. 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 stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving 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., through the Internet using an Internet service provider).

[0136] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of 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 box can also occur in a different order than that marked in the accompanying drawings. For example, two 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 box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0137] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

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

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

[0140] The computer program product provided in this application can address the technical issue of low efficiency in ultra-fast trading systems. Compared to the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the cloud-native ultra-fast trading method provided in the aforementioned embodiments, and are not further elaborated 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 transformations 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 by: The cloud-native high-speed trading system includes a reliable multicast bus encapsulated in a Docker container, a master-slave arbitration module, and at least one serial pipeline provided in a microservice architecture. Multiple business processing units are provided in any of the serial pipelines, and the multiple business processing units are sequentially connected in series. The microservice architecture includes multiple microservices, and the multiple microservices are connected to the master-slave arbitration module. The serial pipelines in the multiple microservices are connected to the reliable multicast bus. 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 configured 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 in 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. There is a one-to-one correspondence between business processing units and business logic operations, and each business processing unit corresponds to a different business logic operation. The reliable multicast bus is used to receive the calculated instruction information and output the calculated instruction information; The business processing unit performs a preset business logic operation on the instruction information, and obtains the operation results including: Each business processing unit in the cloud-native high-speed 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 CPU affinity settings and is bound to the preset CPU NUMA node. Before monitoring whether a master microservice exists among the multiple microservices in the microservice architecture, the cloud-native-based high-speed transaction system is further configured to, upon detecting that at least one microservice has been successfully started, determine whether the microservice is in a preset replay mode; if the microservice is in the replay mode, read the preset target sequence number of the largest consumed message, set the starting sequence number of the preset replay message to the target sequence number plus one, and start replay; The cloud-native-based high-speed transaction system is also used to monitor whether a main microservice exists among multiple microservices in the microservice architecture; If the master microservice exists among the multiple microservices, a slave microservice is determined from other microservices other than 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. If the other microservice receives a synchronization message returned by the master microservice, the other microservice is determined to be a slave microservice; a preset business logic operation is performed on the instruction information according to the business processing unit in the master microservice to obtain an operation result, and when an abnormality is detected in the master microservice, a preset business logic operation is performed on the instruction information according to the business processing unit in the slave microservice to obtain an operation result; If the master microservice does not exist among the multiple microservices, the master microservice among 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.

2. A cloud-native high-speed trading method, characterized by: The cloud-native-based ultra-fast trading method 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, a master-slave arbitration module, and at least one serial pipeline set in a microservice architecture. Multiple business processing units are set in any of the serial pipelines, and the multiple business processing units are connected in series in sequence. The microservice architecture includes multiple microservices, and the multiple microservices are connected to the master-slave arbitration module. The serial pipelines in the multiple microservices are connected to the reliable multicast bus. The cloud-native-based ultra-fast trading method includes: Receiving external instruction information through a reliable multicast bus in the cloud-native high-speed trading system; The business processing unit in the cloud-native high-speed 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 in 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 business processing units have completed the operation, the calculated instruction information is obtained, and the calculated instruction information is output according to the reliable multicast bus; 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: Each business processing unit in the cloud-native high-speed 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 CPU affinity settings and is bound to the preset CPU NUMA node. The cloud-native-based ultra-fast transaction method also includes: Monitor whether a master microservice exists among multiple microservices in a microservice architecture; If the master microservice exists among the multiple microservices, a slave microservice is determined from other microservices other than 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. If the other microservice receives a synchronization message returned by the master microservice, the other microservice is determined to be a slave microservice; a preset business logic operation is performed on the instruction information according to the business processing unit in the master microservice to obtain an operation result, and when an abnormality is detected in the master microservice, a preset business logic operation is performed on the instruction information according to the business processing unit in the slave microservice to obtain an operation result; If the master microservice does not exist in the multiple microservices, the master microservice among the multiple microservices is determined according to the master-slave arbitration module, and a business processing unit in the master microservice performs a preset business logic operation on the instruction information to obtain a business result; The step of monitoring whether a main microservice exists in the multiple microservices of the microservice architecture includes: When it is detected that at least one microservice has been 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.

3. A cloud-native high-speed trading device, characterized by: The cloud-native-based ultra-fast trading device includes: the cloud-native-based ultra-fast trading system as claimed in claim 1, 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 claimed in claim 2.

4. 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 claimed in claim 2.

5. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, implements the steps of the cloud-native-based ultra-fast trading method according to claim 2.

Images