A heterogeneous transaction system

Abstract

The application discloses a heterogeneous transaction system, which can cope with serious software logic defects, realizes that when software failure of an external main system occurs and all emergency safeguard measures are invalid, the business of the main system can be smoothly switched to the heterogeneous transaction system through sending instructions, the continuity of the whole market business is ensured, and the last barrier of guaranteeing the continuity of the business is supplemented.The technical scheme is as follows: the system comprises a transaction front-end module, a market front-end module and a heterogeneous transaction core module; the transaction front-end module is used for client order placing, receiving query requests, protocol conversion and flow control; the market front-end module is used for sending market information to clients in real time through TCP and multicast and processing requests such as login and stream subscription sent by the clients; and the heterogeneous transaction core module is used for data recovery, transaction matching, market generation, query, sequencing and clocking.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial derivative trading systems, in particular to a heterogeneous trading system for the field of financial derivative trading. BACKGROUND

[0002] The trading and settlement system is the most important core system of the exchange and is an important infrastructure in the financial market. The business continuity of the core system is related to the overall stable operation of the financial capital market. At present, the disaster recovery design of "two places and three centers" is generally used in the financial industry, that is, a same-city and an off-site disaster recovery data center are established, but the same software system as the main center is still used. If a software failure occurs in the main center, the disaster recovery center system will most likely encounter the same software defects.

[0003] Therefore, the design of the traditional disaster recovery architecture can only prevent hardware failure risks, and has no effective response to software defect failures. It is a long-term focus and research problem in the industry to prevent both "hard risks" and "soft risks".

[0004] Software reliability is one of the most important measurement indicators in the software quality system, and in the securities and futures industry, the reliability of the core system is particularly important. According to the software reliability theory, defects cannot be completely enumerated, but can only be explored as much as possible through multi-directional testing, verification and other means, and cannot be completely avoided.

[0005] Therefore, how to improve software reliability and ensure core business continuity is one of the difficulties. The existing mature system has a complete hardware failure recovery system such as disaster recovery and remote backup, and can also cope with software failures through application fault tolerance design, disaster recovery design, instruction level automatic obstacle avoidance design and CRIU image recovery. However, there is still a lack of solutions for other software logic defects or architecture level serious defect failures.

[0006] In addition, after the occurrence of software logic defects, the process of switching to a heterogeneous trading system also needs to minimize internal and external influences. On the one hand, the switching efficiency needs to be high, and there should be no impact on the market, and the member side needs to be switched without feeling. On the other hand, there should be no impact on the internal upstream and downstream systems, and the surrounding business systems need to continue to run smoothly after switching. SUMMARY

[0007] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0008] The application aims at solving the above problems, and provides a heterogeneous transaction system, which can cope with serious software logic defects, realizes that when software failure of an external main system occurs and all emergency safeguard measures are invalid, the business of the main system can be smoothly switched to the heterogeneous transaction system through sending instructions, ensures the continuity of the whole market business, and supplements the last barrier of guaranteeing business continuity.

[0009] The technical scheme of the application is as follows: the application discloses a heterogeneous transaction system, which comprises a transaction front-end module, a market front-end module and a heterogeneous transaction core module.

[0010] The transaction front-end module is used for client order placing, receiving query requests, protocol conversion and flow control.

[0011] The market front-end module is used for sending market information to clients in real time through TCP and multicast and processing login and flow subscription requests sent by the clients.

[0012] The heterogeneous transaction core module is used for data recovery, transaction matching, market generation, query, sequencing and clock.

[0013] According to an embodiment of the heterogeneous transaction system, the transaction front-end module is further configured to:

[0014] In the recovery mode, the transaction front-end module is configured to close listening, disable external services and build an index flow through a result flow; and in the matching mode, the transaction front-end module is configured to listen to client connection, manage sessions, process client requests, respond to client requests, manage and decompose data flows, build an index flow through a result flow and perform flow control and internal monitoring.

[0015] According to an embodiment of the heterogeneous transaction system, the market front-end module is further configured to:

[0016] The market front-end module is configured to send market information by topic through TCP, send market information by topic through multicast, check seat login and market information topic subscription and switch between the recovery mode and the matching mode.

[0017] According to an embodiment of the heterogeneous transaction system, the heterogeneous transaction core module is further configured to:

[0018] In the recovery mode, the heterogeneous transaction core module is configured to initialize data recovery and recover transaction data including order books, funds, holdings and market information; and in the matching mode, the heterogeneous transaction core module is configured to perform operations including login, static check, fund and holding check, matching, market generation and contract state switching.

[0019] According to an embodiment of the heterogeneous transaction system, the data transmission mode of the heterogeneous transaction system is divided into a recovery mode and a matching mode, the business pipeline is initially in the recovery mode, no result message is generated, and thus no temporary result stream is written, in the recovery mode, the minimal state set is reconstructed by the minimal heterogeneous core module receiving all results generated by the main transaction system processing, the reconstructed minimal state set is strictly consistent with the state calculated by the main transaction system matching, so as to ensure that no additional preparation time is needed when the switching instruction is received, and the self-combing mode is switched to the matching mode at the moment when the switching instruction arrives, and the business layer is switched to the matching mode after the switching instruction is received, a result message is generated, and the temporary result stream is written.

[0020] According to an embodiment of the heterogeneous transaction system, the business logic model of the heterogeneous transaction system is implemented by using a multi-stage pipeline model, in the multi-stage pipeline model, the business data processing flow is logically divided into several independent parts, each part is driven by a thread, and the threads share a message queue.

[0021] According to an embodiment of the heterogeneous transaction system, the four threads driving the business logic model of the heterogeneous transaction system are an unpacking thread, an authority verification thread, a matching core thread, and a message packing thread, wherein:

[0022] The unpacking thread is configured to unpack the XTP packet uploaded on the heterogeneous transaction system, to generate an original packet header message queue and a 0th-stage message queue of the pipeline;

[0023] The authority verification thread is configured to consume the messages of the original packet header message queue and the 0th-stage message queue, and to generate a 1st-stage message queue;

[0024] The matching core thread is configured to consume the messages of the original packet header message queue and the 0th-stage and 1st-stage message queues, and to generate a 2nd-stage message queue;

[0025] The message packing thread is configured to consume the messages of the original packet header message queue and the 0th-stage, 1st-stage, and 2nd-stage message queues, and to pack the messages into XTP packets for other modules to consume.

[0026] According to an embodiment of the heterogeneous transaction system of the present invention, a dynamic message queue is used to adapt to the multi-level pipeline model. The dynamic message queue consists of an index array layer, a raw packet header message queue, and multi-level message queues. The index array layer is also a message queue structure that maintains the data storage relationship and mainly consists of data address pointers and length information. The raw packet header message queue stores the header information in the raw input message, which consists of the original message number, error code, and engine processing token. The subsequent multi-level message queues are all data storage layers that store the transformed raw messages or intermediate messages generated by each level of the engine. The header information fields include: the order of the raw XTP request packet, whether the process of processing the request carries a transaction, the result of processing the request, and the pipeline stage number that the request has been processed.

[0027] According to an embodiment of the heterogeneous trading system of the present invention, the heterogeneous trading system is further configured with a matching pipeline processing method, the method comprising:

[0028] The subscribing thread receives the uplink message from the external input stream, unpacks it, and verifies the session's validity.

[0029] The verified message is split into a message header and the original message body and stored in a message queue.

[0030] The permission engine reads messages sequentially from the message queue for business processing and attaches new messages generated during the processing to the message queue for processing in the next pipeline stage.

[0031] The matching engine reads messages sequentially from the message queue for business processing and attaches new messages generated during the processing to the message queue for the next stage of the pipeline.

[0032] The packaging thread reads messages sequentially from the message queue and performs transformation and packaging processing.

[0033] The packaging thread transforms and aggregates the packaged messages into a result stream, which is then sent out by the publishing thread.

[0034] Compared with existing technologies, this invention offers the following advantages: By maintaining a heterogeneous transaction system, this invention reduces the overall service failure rate, thereby improving software reliability. In business scenarios with large-scale data volumes and low latency requirements, the heterogeneous transaction system can take over from the main system in real time to provide business services, reducing the possibility of systemic risks caused by software failures.

[0035] This invention's heterogeneous trading system effectively reduces system complexity and significantly compresses R&D and maintenance costs by refining a minimal functional set model. Firstly, in terms of architecture, it shrinks from a distributed system to a monolithic system, stripping away complex functions such as distributed fault tolerance. Secondly, in terms of business logic, it retains only online production-enabled services in principle, ensuring a simplified business application layer. Furthermore, it streamlines core computational logic based on a new, more abstract, multi-layered domain business model rooted in aggregates. Thirdly, regarding external interfaces, it is fully compatible with upstream and downstream systems internally and with member-side systems externally. In the event of a failure, neither the exchange's internal nor external systems require modification, achieving a smooth and seamless switchover, reducing external system modification costs and switching complexity.

[0036] This invention employs recovery mode, matching mode, and in-memory database technology to ensure service quality and performance. Specifically, firstly, under normal backup conditions, the heterogeneous trading system runs in recovery mode, subscribing to the matching result pipeline of the main system in real time, restoring and rebuilding the corresponding business domain state, and ensuring data consistency between the heterogeneous trading system and the main system. In emergency situations involving system switching, the heterogeneous trading system can quickly switch to matching mode to continue providing trading and market data services, ensuring business continuity. Secondly, the matching pipeline processing framework adopts lock-free concurrent message queues, CPU-friendly cached data structures, and zero-copy design. By configuring service components on different pipeline threads for concurrent processing, it fully leverages the performance advantages of multi-processor core hosts, improving matching throughput by 135% under the same hardware conditions, ensuring the high performance of the heterogeneous trading system. Thirdly, regarding the database, the low-latency in-memory database of this invention removes transaction-irrelevant features such as locking mechanisms and concurrent access to simplify the design, supporting features such as data table and data type definitions, transactions with rollback points, trigger-based multi-rollback point transactions, trigger-based multi-type indexes, foreign keys, and multi-level primary keys. Meanwhile, at the architecture layer, large-capacity memory management technology, zero-copy memory technology, and CPU-friendly cache data structure design are employed to minimize memory copying overhead and reduce CPU cache misses. At the data model layer, a powerful data definition language is provided, and a general foreign key association technology is introduced. Using the finest-grained transaction code holdings as the core index, complex data association structures are meticulously organized. By trading space for time, the minimum overhead of approximately one hash index lookup per transaction is achieved, with the remaining connections linked through relationships, greatly reducing computational consumption. Performance testing shows that the processing latency for inserts, updates, and hash looksups with transactions is in the hundreds of nanoseconds. In terms of throughput, insertions reach 2.7 million records / second, updates 2.84 million / second, and hash looksups 4.33 million / second.

[0037] The application integrates a big data monitoring platform, establishes an auxiliary decision-making and one-key switching mechanism for emergency scenarios. In the operation and maintenance aspect, based on the splunk platform based on big data analysis technology, a heterogeneous transaction system intelligent operation and maintenance platform is constructed, and an auxiliary decision-making and one-key switching mechanism supported by data is formed. First, by importing all monitoring data into the splunk big data analysis platform, more than 300 monitoring indicators of more than 70 monitoring panels are established from the aspects of system, service, environment, emergency and log, and combined with the use of big data technology for fault discovery and positioning, scientific data support is provided for the decision of switching the heterogeneous transaction system, and factual basis is provided for the emergency commander to make more accurate switching judgment. Second, the intelligent operation and maintenance platform realizes one-key switching. When a certain error occurs, after the auxiliary decision-making of the operation and maintenance platform, the main system can be switched to the heterogeneous transaction system through one-key switching, which improves the switching accuracy and also greatly improves the switching efficiency, and the switching can be completed in seconds.

[0038] The application first promotes the landing of the core production system in the national security environment and improves the self-controllable ability of the infrastructure. The heterogeneous transaction system fully considers the cross-platform operation demand in the design stage, strictly tests and verifies in the national security environment in the development stage, and ensures the availability of the system in the national security environment. In the national security environment based on the domestic Haiguang server and Kirin operating system, the heterogeneous transaction system runs smoothly, all functions are normal, the delay and throughput performance indicators meet the standards. In order to fully ensure the availability of the heterogeneous transaction system in the national security environment, the following aspects of work are carried out: first, in terms of function, the system accumulates more than 140,000 regression test cases on the national security environment, and passes the production flow inversion comparison test for nearly three years; second, in terms of performance, the characteristics of the national security system are fully explored, and the overall throughput of the system in the national security environment is improved by 8%; third, in terms of drilling, two full-market drills in the production environment are organized in succession, and the system is successfully switched from the non-national security main transaction system to the national security transaction system, and the business runs smoothly. The successful landing of the heterogeneous transaction system in the national security environment realizes the dual heterogeneity of the software layer and the hardware layer, and improves the self-controllable ability of the core system in the infrastructure layer. BRIEF DESCRIPTION OF DRAWINGS

[0039] The above features and advantages of the present application can be better understood after reading the detailed description of embodiments of the present application in conjunction with the following drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related properties or features can have the same or similar reference numerals.

[0040] Figure 1 The overall architecture diagram of an embodiment of the heterogeneous transaction system of the application is shown.

[0041] Figure 2 The overall architecture diagram of an embodiment of the heterogeneous transaction system of the application is shown. Figure 1A process flow diagram of the matching pipeline configured by the system embodiment shown.

[0042] Figure 3 A schematic diagram of the recovery mode of data transmission of the system embodiment shown is shown. Figure 1

[0043] Figure 4 A schematic diagram of the matching mode of data transmission of the system embodiment shown is shown. Figure 1

[0044] Figure 5 A schematic diagram of the multi-stage pipeline model in the business logic processing of the system embodiment shown is shown. Figure 1

[0045] Figure 6A A schematic diagram of one example of a message queue is shown. 6B

[0046] A schematic diagram of one example of the message structure in the dynamic message queue is shown. Figure 7 DETAILED DESCRIPTION

[0047] The present application is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are only exemplary and should not be understood as limiting the scope of protection of the present application in any way.

[0048] Figure 1 The overall architecture of one embodiment of the heterogeneous transaction system of the present application is shown. The heterogeneous transaction system of the present embodiment includes a transaction pre-module, a market pre-module, and a heterogeneous transaction core module.

[0049] The heterogeneous transaction system interacts with the external member counter system through the transaction pre-module and the market pre-module. The heterogeneous transaction core module interacts with the transaction pre-module and the market pre-module, respectively. The heterogeneous transaction system interacts with the external main system through the heterogeneous transaction core module.

[0050] The transaction pre-module is used for client order placement, receiving query requests, protocol conversion, and flow control.

[0051] The transaction pre-module is specifically configured to include closing the listener, disabling external services, and building an index stream through the result stream in the recovery mode; and to include listening to client connections, session management, processing client requests, responding to client requests, data stream management and decomposition, building an index stream through the result stream, flow control, and internal monitoring in the matching mode.

[0052] ​​​​The market data front-end module is used to send market data to clients in real time via TCP and multicast, and to process client requests, including login requests and transaction subscription requests.

[0053] The specific configuration of the market data front-end module is as follows: sending market data by topic via TCP; sending market data by topic via multicast; providing access for seat login and market data topic subscription checks; and switching between recovery mode and matching mode.

[0054] The heterogeneous trading core module is used for data recovery, trade matching, market data generation, querying, sequencing, and clocking.

[0055] The core module of heterogeneous trading is specifically configured as follows: in recovery mode, it performs transaction data recovery including initial data recovery, order book, funds, positions, and market data; in matching mode, it performs operations including login, static checks, fund and position checks, matching, market data generation, and contract status switching.

[0056] Heterogeneous trading systems use two data transmission modes: recovery mode and matching mode. Recovery mode, for example... Figure 3 As shown, the dotted arrows (representing the "data flow before master switch") indicate the initial runtime data flow. The sub (subscription) thread subscribes to the FibProxy (stream distribution proxy) to receive the full flow of data from the main center (main trading system), writes it to a file stream for persistence, and also writes it to the PreSeriesFlow (upstream sequencing stream) for consumption by the business pipeline (right / match / pack threads). The dashed arrows (representing the "data flow after master switch") indicate the data flow after master switch. The tinit (data initialization / real-time deployment module) is subscribed to to receive real-time deployment messages, reads the frontflow, and the pub (publishing) thread begins the persistence of the result stream.

[0057] Matching mode such as Figure 4 As shown, in the matching mode, tinit receives initialization and real-time deployment messages, the sub thread reads the frontflow (ignoring built-in / external), and all read messages are written to PreSeriesFlow (upstream sequencing stream). The framework layer and the business layer interact through the upstream sequencing stream PreSeriesFlow and the temporary result stream TempResultFlow. The pub thread reads the temporary result stream TempResultFlow and persists it as a file stream (CompLog.con), and finally publishes the file stream for downstream modules to consume.

[0058] When the miniKernel (a minimalist heterogeneous core module) unexpectedly restarts, it needs to perform a restart redo. The sub-threads directly read messages from the file stream (CompLog.con) and write them to PreSeriesFlow. The business layer doesn't care whether it's a restart redo or a normal process; it will consume any new data added to PreSeriesFlow. Both PreSeriesFlow and TempResultFlow are memory streams, and they periodically perform pop operations to remove consumed data and free up memory.

[0059] Initially, the business pipeline operates in rebuild mode, generating no result messages and therefore not writing to the temporary result stream TempResultFlow. In rebuild mode, the miniKernel (a minimalist heterogeneous core module) receives all results from the main trading system and reconstructs a minimal state set, including but not limited to order book status, price distribution information, fund holdings information, and global sequence numbers. This reconstructed minimal state set strictly matches the state calculated by the main trading system, ensuring that upon receiving a switch instruction, no additional preparation time is needed; the system instantly switches to match mode upon receiving the instruction. After receiving the switch instruction, the business layer switches to match mode, generates result messages, and writes them to the temporary result stream TempResultFlow.

[0060] When the miniKernel (a minimalist heterogeneous core module) restarts redo, it first reads the file stream (CompLog.con) and needs to restore the subscription points of FibProxy / tinit for renewal. The business layer does not care whether redo is performed; it initially processes in rebuild mode and only switches to match mode when a switch command is encountered.

[0061] The business logic processing of the heterogeneous transaction system in this embodiment adopts the following approach: Figure 5 This is achieved using the multi-stage pipeline model shown.

[0062] In a multi-level pipeline model, the business data processing flow is logically divided into several independent parts, each driven by a thread, and multiple threads share a message queue.

[0063] In its implementation, the heterogeneous transaction system's business model is driven by four threads: pkg (unpacking), right (permission verification), match (matching core), and pack (message packaging). The specific functions of each thread and their interaction with the message queue are as follows.

[0064] Pkg thread (Header / L0-MsgQueue): unpacks the XTP package from the heterogeneous transaction system, generates the original package header message queue Header-MsgQueue and the pipeline's 0th level message queue L0-MsgQueue. The original package header message queue is the key to access the message queue by multiple threads, and controls the read-write permission of the threads on the same message. The 0th level message is usually the original data of the XTP package, that is, the input request package.

[0065] Right thread (L1-MsgQueue): consumes the messages of the original package header message queue Header-MsgQueue and the 0th level message queue L0-MsgQueue, and generates the 1st level message queue L1-MsgQueue.

[0066] Match thread (L2-MsgQueue): consumes the messages of the original package header message queue Header-MsgQueue and the 0th and 1st level message queues L0-MsgQueue and L1-MsgQueue, and generates the 2nd level message queue L2-MsgQueue.

[0067] Pack thread: consumes the messages of the original package header message queue Header-MsgQueue and the 0th, 1st and 2nd level message queues L0-MsgQueue, L1-MsgQueue and L2-MsgQueue, and packs these messages into XTP packages to provide for consumption by other modules.

[0068] The message queues described above save the messages generated by each level of the flow and maintain the correspondence between the messages. The dynamic message queue is a component designed to adapt to the multi-level pipeline model, and its production and consumption mode is tightly coupled with the multi-level pipeline model. For the message queue, the pkg thread is the producer, the pack thread is the consumer, and the right thread and the match thread are both producers and consumers.

[0069] As Figure 6A and 6BAs shown, a detailed data structure diagram of the dynamic message queue (DynamicMsgQueue) is shown: the dynamic message queue is composed of an index array layer (IndexArray), a raw header message queue (Header-MsgQueue), and multi-level message queues (L0-MsgQueue, L1-MsgQueue). The IndexArray is also a message queue structure inside, maintains the storage relationship of data, mainly composed of data address pointer (addr) and length (len) information; the Header-MsgQueue stores the header information (RawHeader) in the original input message, mainly composed of message raw number (rawID), error code (errorID), and engine processing token (engineToken); the subsequent multi-level message queues are data storage layers, storing converted original messages (WriteableMsg) or intermediate messages (WriteableMsg) generated by each level of engine.

[0070] In the message queue, the header structure of the message is crucial. For an original request message and the derived messages generated in each level of the pipeline, the message header records the processing result of the pipeline, and each level of the pipeline judges whether the message is readable through the message header. The message header structure is as shown in Figure 7 As shown, the meanings of each field are as follows: rawID: a serial number of an original XTP request packet, monotonically increasing; bNeedTransaction: whether the process of processing the request carries a transaction; errorID: the result of processing the request; engineToken: the number of the pipeline level that the request has been processed.

[0071] The Pkg thread drives the 0th level message queue of the pipeline model, continuously reads the request XTP packet from the upstream, and performs parsing, extracts the request data, generates the message queue header TRawHeader, writes the TRawHeader into the message queue, and at the same time, the request data is also written into the message queue, at this time, the engineToken field of the TRawHeader corresponding to the request is assigned to 0, indicating that the 0th level message queue has processed the request.

[0072] The first stage message queue of the Right thread-driven pipeline model reads the message header TRawHeader in the order of inserting the message queue according to the message header. If the engineToken of the message header is set to 0, it indicates that the previous stage pipeline has completed the processing of the request corresponding to the TRawHeader, and the current pipeline can process. Thus, the message header TRawHeader and the data corresponding to the TRawHeader in the 0th stage pipeline are read out in order and processed. If a new message is generated after the request is processed by the current pipeline, the generated message is written into the message queue, and then the next request is processed. If the value of the engineToken is not 0 after the message header TRawHeader is read, the current thread is busy waiting until the engineToken is set to 0. After the current thread processes a request, the engineToken field in the TRawHeader is set to 1, indicating that the request has been processed by the first stage pipeline.

[0073] The second stage message queue of the Match thread-driven pipeline model is the same as the Right thread in the production-consumption model. The thread continuously reads the TRawHeader, and when the engineToken is set to 1, the data is read and processed, and the data of the current pipeline is generated, and the engineToken is set to 2. If the engineToken is not 1, the thread is busy waiting.

[0074] The third stage message queue of the Pack thread-driven pipeline model is also judged by the engineToken whether the message corresponding to the TRawHeader is readable. If it is readable, it is read out and packed into an XTP packet, which is provided to other modules for use.

[0075] Figure 2 The system embodiment shown Figure 1 The processing flow of the matching pipeline configured by the system embodiment shown is introduced in detail, and the working content of each thread in the matching pipeline and the pipeline coordination mechanism are introduced in detail as follows.

[0076] Step 1: The Sub (subscription) thread receives the uplink message in the external input stream, performs unpacking and session legality verification.

[0077] Step 2: The verified message is split into MsgHeader (message header) and RawMsg (raw message body) and stored in the message queue.

[0078] Step 3 and 4: RightEngine (the first stage pipeline thread) reads the messages from the message queue in turn to do the relevant business processing, and hangs the new messages generated in the process to the message queue for the next stage pipeline processing.

[0079] Step 5 and 6: TradeEngine (the second stage pipeline thread) reads the messages from the message queue in turn to do the relevant business processing, and hangs the new messages generated in the process to the message queue for the next stage pipeline processing.

[0080] Step 7: Pack (packaging) thread reads the messages from the message queue in turn to do the conversion and packaging processing.

[0081] Step 8: The messages converted and packaged by the Pack thread are aggregated into a result stream for the Pub (publish) thread to send out.

[0082] Although the above methods are illustrated and described as a series of acts, it will be appreciated that the methods are not limited by the order of acts as some acts can, in accordance with one or more embodiments, occur simultaneously or in different orders with respect to other acts described herein or with respect to other acts not described herein but well known by those skilled in the art.

[0083] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0084] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0085] The steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.

[0086] In one or more exemplary embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0087] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A heterogeneous transaction system, characterized by, The system comprises a transaction pre-module, a market pre-module, and a heterogeneous transaction core module, wherein: The transaction pre-module is configured to receive query requests, protocol conversion, and flow control. The market pre-module is configured to send market information to clients in real time through TCP and multicast, and to process login and stream subscription requests from clients. The heterogeneous transaction core module is configured to data recovery, transaction matching, market generation, query, sequencing, and clock. The data transmission mode of the heterogeneous transaction system comprises a recovery mode and a matching mode. The business pipeline starts in the recovery mode and does not generate result messages, so it does not write to the temporary result stream. In the recovery mode, the heterogeneous core module receives all results generated by the main transaction system and reconstructs the minimum state set. The reconstructed minimum state set is strictly consistent with the state calculated by the main transaction system to ensure that no additional preparation time is required when the switching instruction is received. The business layer switches to the matching mode at the moment the switching instruction is received, generates result messages, and writes to the temporary result stream.

2. The heterogeneous transaction system of claim 1, wherein, The transaction pre-module is further configured to: In the recovery mode, it includes closing the listener, disabling external services, and building an index stream through the result stream. In the matching mode, it includes listening to client connections, session management, processing client requests, responding to client requests, data stream management and decomposition, building an index stream through the result stream, and flow control and internal monitoring.

3. The heterogeneous transaction system of claim 1, wherein, The market pre-module is further configured to: Send market information by topic through TCP and multicast, provide seat login and market topic subscription checking, and switch between the recovery mode and the matching mode.

4. The heterogeneous transaction system of claim 1, wherein, The heterogeneous transaction core module is further configured to: In the recovery mode, it includes initializing data recovery, order book, fund, position, and market data recovery. In the matching mode, it includes login, static check, fund and position check, matching, market generation, and contract state switching.

5. The heterogeneous transaction system of claim 1, wherein, The business logic model of the heterogeneous transaction system adopts a multi-stage pipeline model. In the multi-stage pipeline model, the business data processing flow is logically divided into several independent parts, each driven by a thread, and multiple threads share message queues.

6. The heterogeneous transaction system of claim 5, wherein, The four threads driving the business logic model of the heterogeneous transaction system are the unpacking thread, the permission verification thread, the matching core thread, and the message packing thread, wherein: The unpacking thread is configured to unpack the XTP packet uploaded by the heterogeneous transaction system, generate the original packet header message queue, and the 0th stage message queue of the pipeline. The permission verification thread is configured to consume messages from the original packet header message queue and the 0th stage message queue, and generate the 1st stage message queue. The matching core thread is configured to consume messages from the original packet header message queue and the 0th and 1st stage message queues, and generate the 2nd stage message queue. The message packing thread is configured to consume messages from the original packet header message queue and the 0th, 1st, and 2nd stage message queues, and pack these messages into XTP packets for consumption by downstream modules.

7. The heterogeneous transaction system of claim 6, wherein, The dynamic message queue is used to adapt the multi-stage pipeline model, and the dynamic message queue is composed of an index array layer, an original header message queue, and a multi-stage message queue. The index array layer is also a message queue structure inside, which is used to maintain the storage relationship of data, and is composed of a data address pointer and length information. The original header message queue stores the header information in the original input message, which is composed of a message original number, an error code, and an engine processing token. The subsequent multi-stage message queue is a data storage layer, which stores the converted original message or the intermediate message generated by each stage engine. The fields of the header information include: the sequence of the original XTP request packet, whether the process of processing the request carries a transaction, the result of processing the request, and the number of the pipeline stage in which the request has been processed.

8. The heterogeneous transaction system of claim 1, wherein, The heterogeneous transaction system also configures a processing method of the matching pipeline, and the method comprises: The subscription thread receives the uplink message in the external input stream, performs unpacking and session legality verification; The verified message is split into a message header and an original message body and stored in the message queue; The authority engine reads the messages from the message queue in sequence for business processing, and hangs the new messages generated in the processing process to the message queue for the next stage pipeline processing; The matching engine reads the messages from the message queue in sequence for business processing, and hangs the new messages generated in the processing process to the message queue for the next stage pipeline processing; The packing thread reads the messages from the message queue in sequence for conversion and packing processing; The messages converted and packed by the packing thread are summarized into a result stream for the publishing thread to send externally.

Images