A transaction information processing method, system and computer readable storage medium

Abstract

The present invention proposes a transaction information processing method, system and computer-readable storage medium. The method includes receiving a transaction message and processing it, sending the processed transaction message to a transaction engine queue for processing to output a serial transaction message queue; the transaction engine receives the serial transaction message queue output by the transaction engine queue, and processes the transaction messages in the transaction message queue. A transaction information processing system and a computer storage medium are also disclosed. The present invention uses a message queue to process each burst of transaction messages, converts bursts of parallel transaction information into a serial message queue, which is processed by the transaction engine, and decouples the system with the help of a Kafka message queue, thereby improving the message processing efficiency and solving the problem of inability to process in parallel due to DB locks and low transaction processing efficiency.

Description

Technical Field

[0001] The present invention relates to a method and system for processing transaction information in a securities trading system, in particular to a transaction method and system for converting burst transaction messages into a serial message queue. Background Art

[0002] The functions of brokerage trading systems mainly involve fund processing. For example, after a customer deposits money, they can trade stocks, options, digital currencies, foreign exchange, etc. in the trading market. The security of data in transactions is very important. In brokerage trading systems, there will be multiple data accesses. In order to ensure data access security, avoid access conflicts, and ensure data uniqueness and accuracy, the usual practice is to control based on DB locks when processing business, that is, only one operation is allowed to access at the same time, and other access operations must wait. This practice will lead to low concurrency efficiency, which is not conducive to team collaboration, and seriously affects the processing efficiency and processing capacity of the trading system. There is also a problem of high module coupling, which leads to low collaboration efficiency between modules. In addition, the existing trading system is based on DB operations, and there is a problem of high IO overhead, which leads to large transaction delays and does not meet the business needs of high-speed transactions at all. Summary of the invention

[0003] The present invention proposes a transaction information processing method, which receives and processes transaction messages; sends the processed transaction messages to a transaction engine queue for processing to output a serial transaction message queue; the transaction engine receives the serial transaction message queue output by the transaction engine queue, and processes the transaction messages in the transaction message queue.

[0004] In a further solution, the transaction engine receives the serial transaction message queue output by the transaction engine queue and processes the transaction messages in the transaction message queue, including: performing read and write operations on the micro-ledger in the memory according to the transaction message to realize the functions of account query and recording, the micro-ledger contains part of the data of the general ledger, and the number of fields in the micro-ledger is lower than the number of fields in the general ledger.

[0005] In a further embodiment, the micro-ledger includes cash account information, public account information, and margin information.

[0006] In a further solution, a database for backing up the micro-ledger is set up to back up and store the micro-ledger data in the memory.

[0007] In a further solution, the transaction engine receives the serial transaction message queue output by the transaction engine queue and processes the transaction messages in the transaction message queue, and also includes an elimination processing step for removing the corresponding micro-ledger from the memory for accounts that have not had any transactions in the recent period; and for loading the micro-ledger data from the database into the memory when the account has a transaction again after a period of time.

[0008] In a further solution, the transaction engine receives the serial transaction message queue output by the transaction engine queue and processes the transaction messages in the transaction message queue, which also includes an account classification processing step. The transaction engine has multiple micro-ledgers that are differentiated according to account fund size and activity, and distributed to different transaction engines for processing, so that the load of the transaction engine is balanced.

[0009] In a further solution, the transaction engine has multiple corresponding memories. The transaction engine receives the serial transaction message queue output by the transaction engine queue and processes the transaction messages in the transaction message queue, and also includes a disaster recovery processing step. When one of the transaction engines fails, the transaction message sent to the one transaction engine is forwarded to another transaction engine by monitoring the rebalance event of the kafkaconsumer, and the micro-ledger in the memory corresponding to the one transaction engine is cleared, and the micro-ledger is reloaded from the database to the memory corresponding to the one transaction engine.

[0010] In a further scheme, the transaction engine receives the serial transaction message queue output by the transaction engine queue and processes the transaction messages in the transaction message queue, which also includes a fault message processing step: setting an isolation state or a normal state for the account, and recording the isolation state or the normal state of the account in the micro-ledger; and for the account in the isolation state, forwarding the new transaction message in the sending queue to the error queue for queuing and isolation; the message flowing back from the error queue to the sending queue is processed normally; and when the account changes from normal to isolated state, the micro-ledger records the offset of the first message forwarded to the error queue in the error queue as the starting point of subsequent flowing back messages; when the account is in the isolation state, the micro-ledger tracks and records the offset of the most recent isolated message in the sending queue; the recovery program scans the error queue messages from the starting point, and flows the messages of the relevant accounts back to the sending queue for processing again; when the offset of the original sending queue of the flowing back message is equal to the offset of the sending queue of the most recent isolated message recorded in the micro-ledger, it means that all the messages in the error queue have been flowing back and processed, and the account is restored to normal state.

[0011] In a further solution, the transaction engine queue is implemented using the Kafka platform to convert the bursty parallel transaction messages into a serial message sequence. The Kafka platform distributes messages according to the shardingKey. The transaction engine uses the account number as the shardingKey to ensure that the account business messages are consumed and processed by the same transaction engine.

[0012] In a further scheme, the receiving and processing of transaction messages includes one or more of the following steps: receiving and processing asset management business information, and sending the asset management business information to the transaction engine queue for aggregation; receiving and processing transaction feedback information in Fix format fed back by the exchange, performing protocol processing, and sending the transaction feedback information to the transaction engine queue for aggregation; receiving and processing customer transaction request messages, and sending the transaction request messages to the transaction engine queue for aggregation.

[0013] A transaction information processing system is also proposed, including: a transaction message receiving and processing module, which receives and processes transaction messages; a transaction engine queue module, which is used to process the transaction messages sent by the transaction message receiving and processing module and output a serial transaction message queue; a transaction engine, which is used to receive the serial transaction message queue output by the transaction engine queue module and process the transaction messages in the transaction message queue.

[0014] A computer-readable storage medium is also proposed, on which a computer program is stored, characterized in that when the computer program is executed by a processor, the above method is implemented.

[0015] The present invention uses a message queue to process burst transaction messages, converts burst parallel transaction information into a serial message queue, and processes it by the transaction engine. The system is decoupled with the help of the Kafka message queue, which improves the message processing efficiency and solves the problem that DB locks cannot be processed in parallel and the transaction processing efficiency is low. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 The hardware structure diagram of the trading system of the present invention;

[0017] Figure 2 It is a functional module block diagram of the transaction system of the present invention;

[0018] Figure 3 This is a schematic diagram of the data structure of the micro-ledger of the present invention;

[0019] Figure 4 It is a functional module block diagram of the fault message processing mechanism of the Kafka queue in the present invention;

[0020] Figure 5 for Figure 4 Flowchart of sending engine processing fault message;

[0021] Figure 6 It is a flow chart of the recovery procedure in the fault message processing of the present invention. DETAILED DESCRIPTION

[0022] Figure 1 The hardware structure diagram of the trading system of the present invention is shown in FIG. It includes a server 1, a smart mobile terminal 2, a PC 3, and trading systems of major exchanges 4. The server 1 runs the present invention such as Figure 2 In the trading system shown, the server 1 is connected to the smart mobile terminal 2, the PC 3, and the trading systems 4 of various exchanges respectively, and data communication is performed through the communication interface. The server 1 can receive trading instructions, query instructions, etc. from the smart mobile terminal 2 and the PC 3 through the communication interface, process the trading instructions, and feedback trading information according to the trading instructions or return the query information according to the query instructions.

[0023] Embodiment 1

[0024] Figure 2 This is a functional module block diagram of the transaction system of the present invention. In order to solve the problem that DB locks cannot be processed in parallel and the transaction processing efficiency is low, the present invention uses a message queue to process each burst of transaction messages, divides them by module, and decouples the system with the help of a Kafka message queue. The data required by the transaction engine is sent to the transaction engine by each module through Kafka, and the concurrent transaction messages are converted into a sequentially executed transaction message queue, thereby realizing a lock-free design.

[0025] like Figure 2 As shown, the transaction engine 214 of the present invention receives external messages through the transaction engine queue 212 of the Kafka platform and outputs data through Kafka.

[0026] Kafka is an open source stream processing platform written in Scala and Java. The purpose of Kafka is to unify online and offline message processing through Hadoop's parallel loading mechanism, and to provide real-time messages through clusters. Providing message persistence, this structure can maintain long-term stable performance even for TBs of message storage. The present invention uses the kafka platform to process transaction instructions and messages, and can distribute messages according to the characteristics of shardingKey. The transaction engine uses the account number (accountNumber) as the shardingKey to ensure that the account business message is consumed and processed by the same transaction engine, thus ensuring that the messages of the same account are processed in order, achieving the purpose of serialization, so that no lock is required, and the processing efficiency is improved.

[0027] like Figure 2 As shown, the sources of transaction messages sent to the transaction engine 214 are:

[0028] a. Asset management information: customer's deposit and withdrawal, accounts, transfers, risk control, credit and other business information. Figure 2 The asset management module 211 is used to receive asset management business information such as deposits and withdrawals, accounts, transfers, risk control and credit, and converts it into a serial information stream through the Kafka message queue, and then sends it to the transaction engine queue 212 for aggregation. The asset management module 211 specifically includes a deposit and withdrawal, account, transfer message receiving and processing module, a risk control and credit calculation module, a Kafka message queue module, and an asset management module.

[0029] b. Fix-Engine message: mainly involves transaction feedback information fed back by the exchange, including messages such as success and failure of securities transactions. Transaction information is transmitted using the Fix (Financial Information eXchange) protocol. Figure 2 The Fix engine module 213 is connected to major exchanges 3 around the world, routing and transmitting customer transaction data of major exchanges. The Fix engine module 213 includes a Fix engine for submitting transaction requests to trading institutions (such as stock exchanges); and receiving transaction information in Fix format fed back by trading institutions, such as information on successful and failed transactions, and sending the information to the trading engine queue 212 for aggregation. The Fix engine module 213 also includes a Fix message queue module using the Kafka platform, which receives transaction request messages sent by the trading engine 214 and converts them into message queues and sends them to the Fix engine. The Fix engine performs protocol processing and sends the transaction request messages to the securities trading institution 3 through the Fix protocol format in the financial field.

[0030] c. Order Service message: includes customer's order placement, order cancellation and other transaction request messages. Figure 2 The order service module 215 in the embodiment is used for receiving order messages sent from the client 2 or 3, such as stock and futures trading, etc. The client 2 or 3 includes Figure 1 The order service module 215 receives the transaction request of the strategy order placement / cancellation, such as the combination transaction strategy order. After receiving the sudden transaction request message, the order service module 215 sends the transaction request message to the transaction engine queue 212 for aggregation to form a serial message stream sequence. After receiving the transaction request message, the order service module 215 also sends a message to the marketing commission management module for the management of the marketing commission; and sends the transaction request message to the order database (order DB) in a read-only form.

[0031] d. Other messages: including other risk control messages and account messages.

[0032] like Figure 2 As shown, the data output by the trading engine 214 include customer fund changes, order changes, change logs, trading request messages and other messages. The downstream module performs operations such as customer position changes, fund settlement, order transaction registration, message push to the APP end, and Fix engine module 213 submits trading request messages to the exchange for trading based on these data.

[0033] Specifically, the Kafka transaction engine queue 214 receives the above transaction messages and converts them into a message queue and outputs them to the transaction engine 214 .

[0034] The trading engine 214 sequentially receives trading messages from the Kafka trading engine queue module 214 and processes and outputs them: the trading request information is sent to major exchanges through the Fix queue for trading. The trading engine 214 reads and writes the account information in the memory 216 according to the trading messages and asset management messages returned by the exchange to update the account information; the information such as fund changes, order changes, and change logs are sent to the fund queue module, and then the subsequent position changes, fund settlement, order transaction registration, and the message is pushed to the APP end. Specifically, the order change message in the fund queue is sent to the order maintenance module to write to the order database to register the order transaction; the fund change message in the fund queue is sent to the fund maintenance module to update the fund database; the fund change message in the fund queue is also sent to the clearing queue and the clearing service module to clear funds; the message in the fund queue is also sent to the real-time computing engine, and then the message is pushed to the APP end 1 and 2 through the real-time asset message queue.

[0035] For the trading engine, some external data is also required. These data are divided into two categories:

[0036] (1) Data that changes very frequently, such as market quotes. For this type of data, the data is stored in Redis and read directly from Redis through the interface, which is also very efficient.

[0037] (2) Data is relatively fixed. Typical data include: underlying data, margin rate, trading calendar, etc. With the help of the push system, the trading engine 214 receives the data and saves it in the memory 216. The trading engine 214 directly accesses the memory 216, which is very efficient.

[0038] The real-time computing engine can receive quotation services (such as market conditions), form strategic orders and strategic withdrawal orders (such as buy and sell combination orders), send them to the strategic order placement / cancellation queue, and then send them to the order service module 215. The real-time computing engine also sends the quotation information to the client 2, 3 in real time through the real-time asset message queue, so that the client information is updated.

[0039] The above modules containing queues, such as the transaction engine queue and Fix message queue, can all be implemented using the Kafka platform to convert bursty parallel data into serial message sequences.

[0040] As can be seen from the above, the trading system of the present invention mainly has the following characteristics:

[0041] 1. Lock-free design:

[0042] like Figure 2 As shown, the transaction engine of the present invention receives external messages through Kafka and outputs data through Kafka. With the feature that Kafka can distribute messages according to shardingKey, the transaction engine uses the account number (accountNumber) as the shardingKey to ensure that the account business messages are consumed and processed by the same transaction engine, thus ensuring that the messages of the same account are processed in order, achieving the purpose of serialization, and thus no lock is required.

[0043] 2. Read-write separation:

[0044] from Figure 2 As can be seen from the business process diagram, data flows in one direction. For example:

[0045] Order (write): account transaction request -> order service 215 (OrderService) -> kafka transaction engine queue 212 -> transaction engine 214 (Engine) -> Fix message queue and fix engine (FixGw) -> kafka transaction engine queue 212 -> transaction engine 214 (Engine) -> funds queue (AssetsBus) -> order maintenance (OrderPersist).

[0046] Query (read): After order maintenance (OrderPersist) is persisted to the order DB, the account can query from the order DB. When the data volume increases to a certain level, the order data will be loaded into the search engine and provided to the account for query.

[0047] Embodiment 2

[0048] In the existing trading system, based on DB operations, each transaction needs to read and write IO (Input Output) to the database (such as MySQL), resulting in large input and output overhead and large transaction delays, which cannot meet the business needs of high-speed transactions.

[0049] Usually, an account has a very large number of data items. For the transaction engine, it is not necessary to process all the data items in the account in the transaction. The transaction only involves the processing of some basic information. Therefore, for performance considerations, the present invention, in one embodiment, designs a micro-ledger, referred to as the small account, and adopts the design of the small account of the transaction engine. The small account contains some basic account information used in the transaction, thereby streamlining the data volume and reducing IO overhead.

[0050] like Figure 3 The following is a schematic diagram of the data structure of the micro-ledger in the present invention. The main structure of the small account is as follows: it mainly includes three types of basic information: cash account information, public account information, and margin information. For each type of information, it only contains the basic data information items used in the transaction. The small account contains part of the data of the general ledger and is a simplified version of the general ledger. The number of fields in the small account is less than the number of fields in the general ledger.

[0051] Among them, cash account information includes two types of cash (Cash) settled funds information and unsettled funds information. Settled funds information includes the following data items: account ID, currency, settled amount, deposit credit amount, cashable amount at the beginning of the day, frozen amount, in-transit deposit, ATW1, etc.; unsettled funds information includes: account ID, currency, category, T+1 unsettled amount, T+2 unsettled amount, used settled amount, usedT+1 unsettled amount, usedT+2 unsettled amount, etc.

[0052] Public account information includes five types of data information: main order, sub-order, sub-order execution order, position, and public attributes. Among them, the main order information includes: main order ID, order strategy (JSON), order type, unfulfilled sub-order ID list, clientRefID, etc.; sub-order information includes sub-order ID, main order ID, currency, category, Side, Status, instrID, leaveQty, Type, bpPrice, execOrderID, replaceOrderID, execOrderStatus, etc.; sub-order-execution order information includes: execution order ID, sub-order ID, main order ID, etc.; position information includes: instrID, currency, category, Qty, avgPrice, todayOpenQty, dtFlag, etc.; public attribute information includes: account type, day cut date, Offset, transaction restrictions, etc.

[0053] Margin account information includes two types of information: control attribute information of margin and fund information. Among them, control attribute information includes: DT times in the previous 4 days (array), DT times on the current day, intraday margin rate, maintenance margin rate, RegT margin rate, comprehensive cashable amount (excluding financing), comprehensive cashable amount (including financing) and other data items. Fund information includes: account ID, currency, cash, deposit credit amount, frozen amount, in-transit deposit, SMA1, ATM1-no financing, ATW1-financing and other data items.

[0054] Different attribute data are designed for the small accounts of different accounts according to the account type. Only the customer's pending orders are retained in the small account (the account pending order data is not maintained), and the account small account data is always kept concise.

[0055] In addition, the small account has some other features:

[0056] 1. Secondary cache: In order to prevent the loss of small account data in memory 216 due to server abnormality, the small account storage will be divided into secondary storage, that is, the small account data will be stored in memory 216 and another database (such as MongoDB) respectively. The transaction engine 214 will first read the small account from memory 216 and then read the small account from MongoDB. The small account data is backed up in memory 216 and MongoDB through an intermittent backup mechanism, which ensures data security and reduces the amount of data reading and writing. The transaction engine serializes account data and writes it at a single point to ensure that the small account information is read from memory 216 in most cases.

[0057] 2. Elimination strategy: Since there are a lot of account data, but relatively few customers actually participate in transactions, the transaction engine sets a cold data removal strategy. For accounts that have not had transactions in the recent period, the corresponding small accounts are removed from the memory 216, reducing the memory 216 consumption of the transaction engine. When the account has transactions again after a period of time, the small account data is loaded from the database (DB) and saved in the memory 216.

[0058] 3. Account classification: Accounts are classified according to their fund size and activity, and allocated to different trading engines to prevent a large number of large customers from gathering in one trading engine, causing the trading engine to be overloaded, so that the load of the trading engine is balanced.

[0059] 4. Disaster recovery mechanism: Assuming that there are currently two trading engines, when one of the trading engines fails, by monitoring the rebalance event of Kafkaconsumer, the business message of the account will be forwarded to the other trading engine, thus achieving 24-hour uninterrupted service. There is a special note here: Since the small account data adopts a two-level cache design, when Kafka rebalance occurs, the small account information in memory 216 must be cleared and the small account must be reloaded from the DB to memory 216 to prevent data contamination.

[0060] Embodiment 3

[0061] Figure 4 It is a functional module block diagram of the fault message processing mechanism of the Kafka queue in the present invention.

[0062] Figure 4 Explanation of the figure marks: 41 new message, 42 cannot be processed normally, 43 isolated forwarding, 44 backflow message, 45 backflow message, 46 can be processed normally; 4001 kafka message sending queue (TxBus), 4002 sending engine (TxEngine), 4003 error message queue (ErrorBus).

[0063] In order to process fault messages, the present invention sets an error message queue 4003 (ErrorBus) outside the Kafka message sending queue 4001 (TxBus) to isolate fault messages. If an account is in an isolated state, the new message 41 related to the account will be isolated when it is sent to the sending engine 4002 (TxEngine) through the Kafka message sending queue 4001 (TxBus) (such as signal line 42), that is, forwarded to the error message queue 4003 (ErrorBus) for queuing and processing (such as signal line 43). The Kafka message sending queue 4001 (TxBus) can be Figure 2 Any Kafka queue in, for example, a transaction engine queue, a Fix engine queue, or a fund queue, etc., the sending engine 4002 (TxEngine) can be Figure 2 The computing engine corresponding to the above-mentioned Kafka queue, such as the transaction engine 214, the Fix engine, or the real-time computing engine.

[0064] Specific methods include:

[0065] (1) Accounts have two states: isolated and normal, which are recorded in the small account;

[0066] (2) In the isolated state, the new message 41 in the TxBus cannot be processed directly, but must go through "isolation review" - transferred to the ErrorBus to queue (such as signal line 43); while the message flowing back from the ErrorBus to the TxBus can be processed normally (such as signal lines 45 and 46);

[0067] (3) After the account changes from normal to isolated state, the small account needs to record the offset of the first isolated message in ErrorBus as the starting point of subsequent return messages;

[0068] (4) In the isolated state, the small account needs to track and record the offset of the most recent isolated message in the sending queue (TxBusoffset);

[0069] (5) The recovery program scans the ErrorBus messages from the starting point and flows the messages of the relevant accounts back to the TxBus for further processing;

[0070] (6) When the original send queue offset (TxBusoffset) of the reflow message == the send queue offset (TxBusoffset) of the most recent isolated message recorded in the small account, it means that all messages in the ErrorBus have been reflowed and processed, and the account is restored to normal status;

[0071] (7) It is common for errors to occur again in the backflow message processing during the recovery process. In this case, the recovery task should be interrupted;

[0072] (8) The message flowing back to TxBus will have a new offset. At this time, the original offset should be used for business judgment instead of the new offset. Another great benefit of using the original offset for judgment is that there is no need to perform deduplication processing when flowing back to TxBus.

[0073] Embodiment 4

[0074] Figure 5 for Figure 4 Flow chart of sending engine 4002 processing fault message. The specific steps of sending engine 4002 processing fault message include:

[0075] S51, the sending engine 4002 obtains the message from the message sending queue 4001 (TxBus), and goes to S52;

[0076] S52, determine whether it is an isolation command, if not, go to S53; if it is an isolation command, determine whether the account is in a normal state? If not, it indicates that the account is already in an isolation state, and the processing ends; if it is not in an isolation state, the account is set to be isolated, and the processing ends;

[0077] S53, determine whether it is a recovery command, if not, go to S54; if it is a recovery command, determine whether the account is in an isolated state, if not, end the processing, if yes, determine whether the isolation message is empty, if not, record the recovery batch ID and end the processing, if the isolation message starting point is empty, set the account to normal, and send a success message (with the recovery batch ID) to ErrorBus;

[0078] S54, determine whether the account has been isolated; if it has been isolated, go to S55, if not, go to S59;

[0079] S55, determine whether the message is an ErrorBus return message, if it is a return message, go to S56; if it is not a return message, indicating that the message is a new message that should be isolated, then the new message is forwarded to the ErrorBus, and the TxBusOffset of the most recently isolated message is updated, and it is determined whether the start point of the isolated message is empty, if not, the processing is terminated, if yes, the isolation start point message is updated, and the processing is terminated;

[0080] S56. If it is determined in S55 that the message is a return message of ErrorBus, determine whether the ID of the message reply batch is equal to the small account recovery batch ID. If not, end the process; if yes, go to S57;

[0081] S57, update the starting point of the isolation message to the offset (Offset) of the message ErrorBus; and go to S58;

[0082] S58, replace the message Offset with the original TxBusoffset of the message; go to S59;

[0083] S59, process the message normally; and go to S5A;

[0084] S5A, determine whether the specified exception is thrown and request isolation? If yes, go to S5B, if no, determine whether the account is in the isolated state, if no, end the processing, if yes, determine whether the offset of the original TxBus of the message is equal to the TxBusoffset of the most recent isolated message of the small account, if no, end the processing, if yes, set the account to normal, and send a success message (with the recovery batch ID) to ErrorBus;

[0085] S5B, determine whether the account is in the isolated state? If yes, go to S5C; otherwise, forward the message to ErrorBus, update the TxBusoffset of the most recently isolated message, and set the account to be isolated;

[0086] S5C: reset the recovery batch ID, ignore subsequent return messages of the same batch, and end the processing.

[0087] Embodiment 5

[0088] Figure 6 It is a flow chart of the recovery procedure for fault message processing of the present invention. Figure 4 The recovery program module 4004 executes the recovery program, including the following steps:

[0089] S61, determine whether there is a recovery program for the same account running? If not, go to S62; if yes, end the process;

[0090] S62, X = ErrorBus maximum offset + 1, recovery batch ID = UUID; go to S63;

[0091] S63: Determine whether the account is in an isolated state. If not, end the process; if yes, go to S64;

[0092] S64. Determine whether the starting point of the small account isolation message is empty. If not, go to S65. If yes, set the starting point to X and go to S65.

[0093] S65, sending a recovery command message (with recovery batch ID) to TxBus; go to S66;

[0094] S66, scan the messages of the account in ErrorBus from the starting point; go to S67;

[0095] S67, determine whether it is a success message? If not, go to S68; if yes, determine whether the recovery batch ID matches? If it matches, end the process; if not, go to S70;

[0096] S68, mark the message with a return mark, and carry the recovery batch ID, Errorbusoffset, and original TxBusoffset; go to S69;

[0097] S69, forward the message to TxBus; go to S70;

[0098] S70, wait for the next message, and go to S67.

[0099] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the aforementioned disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

Claims

1. A transaction information processing method, characterized in that: include: Receive transaction messages and process them; Sending the processed transaction message to a transaction engine queue (212) for processing to output a serial transaction message queue; The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212), and processes the transaction messages in the transaction message queue; The transaction engine (214) receives external messages through the transaction engine queue (212) of the Kafka platform, and outputs data through the Kafka platform; The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212) and processes the transaction message in the transaction message queue, including: performing read and write operations on the micro-ledger in the memory (216) according to the transaction message to realize the functions of account query and recording, wherein the micro-ledger includes part of the data of the general ledger, and the number of fields in the micro-ledger is less than the number of fields in the general ledger.

2. The method according to claim 1, characterized in that The micro-ledger includes cash account information, public account information and margin information.

3. The method according to claim 1, characterized in that A database for backing up the micro-ledger is set to back up and store the micro-ledger data in the memory (216).

4. The method according to claim 1, characterized in that The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212) and processes the transaction messages in the transaction message queue, and also includes an elimination processing step for removing the corresponding micro-ledger from the memory (216) for accounts that have not had transactions in the recent period; and for loading the micro-ledger data from the database into the memory (216) when the account has a transaction again after a period of time.

5. The method according to claim 1, characterized in that The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212) and processes the transaction messages in the transaction message queue, which also includes an account classification processing step. The transaction engine (214) has multiple micro-ledgers that are differentiated according to account fund size and activity, and distributed to different transaction engines (214) for processing, so that the load of the transaction engine (214) is balanced.

6. The method according to claim 1, characterized in that The transaction engine (214) has multiple and corresponding memories (216). The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212) and processes the transaction messages in the transaction message queue, and also includes a disaster recovery processing step. When one of the transaction engines (214) fails, the transaction message sent to the one transaction engine is forwarded to another transaction engine by monitoring the rebalance event of the kafkaconsumer, and the micro-ledger in the memory (216) corresponding to the one transaction engine is cleared, and the micro-ledger is reloaded from the database to the memory (216) corresponding to the one transaction engine.

7. The method according to claim 1, characterized in that The transaction engine (214) receives the serial transaction message queue output by the transaction engine queue (212) and processes the transaction messages in the transaction message queue, further comprising a fault message processing step: Setting an isolated state or a normal state for an account, and recording the isolated state or the normal state of the account in the micro-ledger; And for accounts in isolation, new transaction messages in the sending queue are forwarded to the error queue for isolation; messages flowing back from the error queue to the sending queue are processed normally; When the account changes from a normal state to an isolated state, the micro-ledger records the offset of the first message forwarded to the error queue in the error queue as the starting point of subsequent return messages; When the account is in quarantine, the micro-ledger tracks and records the offset of the most recent quarantined message in the sending queue; The recovery program scans the error queue messages from the starting point and flows the messages of the relevant accounts back to the sending queue for further processing; When the offset of the original sending queue of the reflow message is equal to the offset of the sending queue of the most recent isolated message recorded in the micro-ledger, it means that all messages in the error queue have been reflowed and processed, and the account will be restored to normal status.

8. The method according to any one of claims 1 to 7, characterized in that: The transaction engine queue (212) is implemented using the Kafka platform to convert the bursty parallel transaction messages into a serial message sequence. The Kafka platform distributes messages according to the shardingKey. The transaction engine uses the account number (accountNumber) as the shardingKey to ensure that the account business messages are consumed and processed by the same transaction engine (214).

9. The method of claim 1, wherein receiving and processing a transaction message (211, 213, 215) comprises one or more of the following steps: Receiving and processing asset management business information, and sending the asset management business information to the transaction engine queue (212) for aggregation; Receive and process the transaction feedback information in the Fix format fed back by the exchange, perform protocol processing, and send the transaction feedback information to the transaction engine queue (212) for aggregation; Receive and process the transaction request message from the customer, and send the transaction request message to the transaction engine queue (212) for aggregation.

10. A transaction information processing system, characterized in that: include: A transaction message receiving and processing module (211, 213, 215), receiving and processing transaction messages; A transaction engine queue module (212), used for processing the transaction messages sent by the transaction message receiving and processing modules (211, 213, 215) and outputting a serial transaction message queue; The transaction engine (214) is used to receive the serial transaction message queue output by the transaction engine queue module (212), and process the transaction messages in the transaction message queue; The transaction engine (214) receives external messages through the transaction engine queue (212) of the Kafka platform, and outputs data through the Kafka platform; The transaction engine (214) performs read and write operations on the micro-ledger in the memory (216) according to the transaction message to realize the functions of account query and recording, wherein the micro-ledger includes part of the data of the general ledger, and the number of fields in the micro-ledger is less than the number of fields in the general ledger.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images