A message sorting method, apparatus, electronic device, and program product

Abstract

This application proposes a message sorting method, apparatus, electronic device, and program product. It obtains raw messages through a distribution thread pool and assigns messages from the same business process to the same unsorted queue. Sorting thread pool worker threads read messages and store them in a thread-local cache set. Based on message dependencies within the business process, it determines sendability; messages that meet the conditions are sent to the subscription queue, while those that do not are retained in the cache. This mechanism effectively solves the problem of out-of-order messages for the same business process caused by multiple exchanges and network latency in message middleware, avoiding data inconsistency and business anomalies. A unified sorting logic replaces redundant development on the subscriber side, reducing system complexity. Through thread pool division of labor, local cache storage, and a caching strategy for messages that do not meet the conditions, it reduces interaction overhead and balances message ordering and low latency requirements in high-frequency trading scenarios, improving processing throughput, real-time performance, and resource utilization under high concurrency.

Description

Technical Field

[0001] This application relates to the field of communication technology for financial transaction systems, and more specifically, to a message sorting method, apparatus, electronic device, and program product. Background Technology

[0002] The message ordering guarantee technology based on the publish / subscribe model of the event-driven architecture is suitable for financial transaction scenarios such as securities, futures, and options that require high concurrency and low latency processing. It can ensure that business event messages are flowed to downstream business modules in the correct logical order.

[0003] In existing financial transaction systems, the core component, acting as the publisher, encapsulates business events such as "order placement," "trade," and "order cancellation" into messages, which are then published through the message middleware's exchange. Downstream subscribers, such as risk control and clearing, consume the messages from the corresponding queues. Furthermore, each subscriber needs to implement its own caching and sorting logic to address the message out-of-order problem.

[0004] However, existing technologies have significant drawbacks: message middleware, due to its characteristics such as multiple switches and network latency, is prone to causing messages for the same business to be out of order, leading to data inconsistencies and business anomalies; each subscriber repeatedly develops sorting logic, increasing system complexity; in high-frequency trading scenarios, traditional sorting schemes are prone to becoming performance bottlenecks, unable to balance message ordering and low latency requirements, and thus failing to meet business needs. Summary of the Invention

[0005] The purpose of this application is to provide a message sorting method, apparatus, electronic device, and program product to reduce the cost of sorting processing and improve message processing efficiency in high-frequency trading scenarios.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, embodiments of this application provide a message sorting method, including:

[0008] The distribution thread pool retrieves raw messages from each subscribed message queue of the message middleware;

[0009] The distribution thread pool assigns the original messages of the same business process to the unsorted original message queue of the same distribution thread;

[0010] The worker threads of the sorting thread pool read the original messages from the corresponding unsorted original message queue and store them in the thread's local cache set;

[0011] The worker thread determines the sendability of messages in the cache set based on message state dependency rules; the message state dependency rules represent the dependency relationships between different messages in the same business process.

[0012] If the sending conditions are met, the corresponding message will be sent to the subscription queue as an ordered message; if the sending conditions are not met, the corresponding message will be kept in the cache set.

[0013] Secondly, embodiments of this application provide a message sorting apparatus, comprising:

[0014] The distribution thread pool is used to retrieve raw messages from each subscribed message queue of the message middleware; and to distribute raw messages of the same business process to the unordered raw message queue of the same distribution thread.

[0015] The sorting thread pool is used to read raw messages from the corresponding unsorted raw message queue through worker threads and store them in a local cache set. Based on message state dependency rules, the sendability of messages in the cache set is determined. The message state dependency rules represent the dependency relationship between different messages in the same business process. If the sending condition is met, the corresponding message is sent to the subscription queue as an ordered message. If the sending condition is not met, the corresponding message is kept in the cache set.

[0016] Thirdly, embodiments of this application provide an electronic device, including:

[0017] Memory, used to store one or more programs;

[0018] processor;

[0019] When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.

[0020] Fourthly, embodiments of this application provide a program product that, when executed by a processor, implements the method as described in any one of the first aspects above.

[0021] Compared to existing technologies, the message sorting method, apparatus, electronic device, and program product provided in this application obtains original messages through a distribution thread pool and allocates messages of the same business process to the same queue to be sorted. The sorting thread pool worker threads read messages and store them in a thread-local cache set. Based on rules representing message dependencies within the business process, sendability is determined; messages that meet the conditions are sent to the subscription queue, while those that do not are retained in the cache. This mechanism effectively solves the problem of out-of-order messages of the same business process caused by multiple switches and network latency in message middleware, avoiding data inconsistency and business anomalies. A unified sorting logic replaces redundant development on the subscriber side, reducing system complexity. Through thread pool division of labor, local cache storage, and caching strategies for messages that do not meet the conditions, interaction overhead is reduced. In high-frequency trading scenarios, it balances message ordering and low latency requirements, improving processing throughput, real-time performance, and resource utilization under high concurrency. Simultaneously, the rules are independent of the core process, enhancing business adaptability flexibility.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of a publisher-consumer model for existing technologies;

[0025] Figure 2 This is a diagram illustrating the correspondence between business events, business processes, and messages.

[0026] Figure 3 This is an example illustration of a dependency relationship provided in an embodiment of the present invention;

[0027] Figure 4 A schematic diagram of a message sorting device provided in an embodiment of the present invention;

[0028] Figure 5 A flowchart illustrating a message sorting method provided in an embodiment of the present invention;

[0029] Figure 6 A schematic diagram of another message sorting device provided in an embodiment of the present invention;

[0030] Figure 7 A flowchart illustrating another message sorting method provided in an embodiment of the present invention;

[0031] Figure 8 A schematic diagram of another message sorting device provided in an embodiment of the present invention;

[0032] Figure 9 A flowchart illustrating another message sorting method provided in an embodiment of the present invention;

[0033] Figure 10 A flowchart illustrating another message sorting method provided in an embodiment of the present invention;

[0034] Figure 11 A flowchart illustrating another message sorting method provided in an embodiment of the present invention;

[0035] Figure 12A flowchart illustrating another message sorting method provided in an embodiment of the present invention;

[0036] Figure 13 This is another example illustration of dependency relationships provided in an embodiment of the present invention;

[0037] Figure 14 This is another example illustration of dependency relationships provided in an embodiment of the present invention;

[0038] Figure 15 A schematic diagram of another message sorting device provided in an embodiment of the present invention;

[0039] Figure 16 A schematic diagram of another message sorting device provided in an embodiment of the present invention;

[0040] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0042] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0043] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0044] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0045] Figure 1 This is a schematic diagram of a publisher-consumer model for existing technologies. (See attached image) Figure 1 In modern financial trading systems (such as securities, futures, and options trading systems), event-driven architecture (EDA) is commonly used: a publisher (Pub) and subscriber (Sub) pattern is employed for system decoupling and asynchronous communication. Core system components (such as order management and transaction processing) act as message publishers, encapsulating business events (such as "order placement," "order execution," and "order cancellation") into messages and publishing them to specific exchanges in a message middleware (such as RabbitMQ). Multiple downstream business modules (such as risk control, clearing, and querying) act as subscribers, consuming these messages from their respective subscription queues.

[0046] However, existing technologies have a significant technical drawback: message timing cannot be guaranteed. Due to the architectural characteristics of message middleware (such as different switches, different subscription queues, network latency, and differences in consumer processing speed), for the same business transaction (e.g., a transaction with order ID 123), multiple messages generated (such as the "transaction placed" message and the subsequent "transaction completed" message) may be received by downstream subscribers in the wrong order. For example, a subscriber may receive the "transaction completed" message first, and then receive the "transaction placed" message.

[0047] Such message out-of-order delivery can lead to serious business logic errors:

[0048] 1) Data inconsistency: When processing "transaction" messages, the system fails or generates dirty data because it cannot find the corresponding "order" record.

[0049] 2) Business anomalies: Risk control, clearing and other modules may make incorrect judgments based on an incorrect sequence of events, which may lead to compliance risks or financial losses.

[0050] 3) High system complexity: Each downstream subscriber must implement complex caching and sorting logic to deal with out-of-order problems, which not only leads to redundant development but is also prone to errors and difficult to maintain.

[0051] The aforementioned problems are amplified dramatically, especially in high-concurrency, low-latency scenarios such as high-frequency trading and algorithmic trading. These systems need to process tens of thousands or even hundreds of thousands of order requests per second, with end-to-end latency requirements typically in the millisecond or even microsecond range. Under these stringent performance constraints:

[0052] High throughput pressure: A massive influx of messages poses a significant challenge to the processing capabilities of message middleware and downstream systems. Inefficient sorting logic can easily become a system bottleneck, leading to message backlog, soaring processing latency, and failure to meet real-time requirements.

[0053] Low latency sensitivity: Any additional processing overhead (such as complex cross-thread synchronization, frequent disk I / O, inefficient cache lookups) will significantly increase the latency of the message processing chain. Traditional sorting schemes that rely on global locks or centralized storage often fail to meet the requirements in this scenario due to lock contention or I / O waiting.

[0054] Increased resource contention: In high-concurrency environments, competition for shared state (such as caches used for sorting) among multiple threads / processes becomes exceptionally fierce. Inappropriate concurrency control strategies can not only reduce throughput but also lead to system instability due to issues such as deadlocks.

[0055] Therefore, existing solutions that delegate sorting complexity to individual business subscribers face severe challenges in high-concurrency, low-latency scenarios: it is difficult to balance ensuring the absolute order of messages to maintain business correctness with achieving the ultimate processing performance to meet timeliness requirements.

[0056] Because a series of events can constitute business processes with multiple scenarios, each business process will generate a response message based on its processing stage. The following example illustrates the relationship between business time, business processes, and messages. Specifically, Figure 2 This is a diagram illustrating the correspondence between business events, business processes, and messages. (See attached image) Figure 2 It provides multiple possibilities for the corresponding relationships:

[0057] Business Process A: Order Placement → Order Confirmation → Order Transaction;

[0058] Business Process B: Order Placement → Order Confirmation → Order Cancellation → Order Cancellation Completed;

[0059] Business Process C: Order Placement → Order Confirmation → Order Cancellation → Order Cancellation (Return to Order Confirmation Status);

[0060] Business Process D: Order Placement → Order Confirmation → Order Cancellation → Order Cancellation (Return to Order Confirmation Status) → Order Cancellation → Order Cancellation Completed;

[0061] Business Process E: Order Placement → Order Confirmation → Order Transaction 1…Order Transaction N (Transactions in Parts), until all order quantities are completed;

[0062] Business Process F - Branch 1: Order Placement → Order Confirmation → Order Cancellation → Order Completed; Branch 2: Order Placement → Order Confirmation → Partial Order Transaction Completed;

[0063] Business Process G - Branch 1: Order Placement → Order Confirmation → Order Cancellation → Order Cancellation (Return to Order Confirmation Status); Branch 2: Order Placement → Order Confirmation → Partial Order Transaction.

[0064] Optionally, this application does not exhaustively list all possible business processes, and other possibilities may exist, such as: Business Process H: Business Process D (Partial Withdrawal) + Business Process E (Partial Completion) (Partial Withdrawal first, then Completion); Business Process J: Business Process E (Partial Completion) + Business Process D (Partial Withdrawal) (Completion first, then Withdrawal). Therefore, the form of the business process is not limited.

[0065] "Partial completion" refers to the completion of a partial transaction, "partial cancellation" refers to the partial cancellation of an order, and "cancellation completion" refers to the completion of a cancelled order. For example, if an order is placed for 1000 shares of stock A, "500 shares partially completed" means that 500 shares were traded; "300 shares partially cancelled" means that 300 shares were cancelled; and "cancellation completion" means that the cancellation was successful. The remaining 200 shares may be either partially completed or partially cancelled.

[0066] Based on the above business process example, the inventors discovered that for each message corresponding to a business practice, there is a dependency relationship between it and the messages preceding and following it within the business process. Optionally, taking business process F as an example, the following provides an example of illustrating the dependency relationship. Specifically, Figure 3 This is an example illustration of a dependency relationship provided in an embodiment of the present invention. See also... Figure 3 The entire business process can be layered according to the dependencies of business events: from left to right, they are L0, L1, L2 and L3.

[0067] In this context, L0 corresponds to the business event "Order Placement," and L1 corresponds to the business event "Order Confirmation." For "Order Confirmation," its subordinate business events have two possibilities: 1. Order Cancellation; 2. Partial Order Transaction. Therefore, L2 corresponds to either "Order Cancellation" or "Partial Order Transaction." For "Order Cancellation," its subordinate business event is "Order Cancellation Completed," therefore, L3 corresponds to "Order Cancellation Completed."

[0068] Correspondingly, for each business event, its corresponding message has a hierarchical dependency relationship: First, for message 1 in L0, as the initial state message, there are no upper-level messages with dependencies. Its lower-level message with dependencies is message 2.

[0069] For message 2, since there are two related business practices in L2, the lower-level messages of message 2 are message 3 and message 5.

[0070] For message 3, its lower-level message is message 4 in L3.

[0071] As for messages 4 and 5, they each belong to the last layer of the business event processing branch process, and therefore they are messages with a terminated state.

[0072] It should be noted that for "partial order completion", there can be multiple corresponding message 5s. That is, if the number of orders in the business data is "10" and the number of order cancellations is "6", then the number of partially completed orders should be at least "4". Therefore, there can also be multiple message 5s used to notify of partially completed orders.

[0073] Clearly, given the complex ordering of business processes and corresponding messages, existing technical solutions cannot effectively avoid out-of-order issues. Therefore, the applicant proposes a sorting mechanism to ensure subscribers receive messages in an ordered manner. Specifically, Figure 4 This is a schematic diagram of a message sorting device provided in an embodiment of the present invention. See also: Figure 4 In addition to the publisher 10, message middleware 11, and subscriber 12, this application also adds a sorting component 13, which is used to sort messages in the same business process and deliver the ordered messages to the message queue 11 so that the subscriber 12 can obtain the ordered messages.

[0074] The sorting component 13 is equipped with a distribution thread pool 130 and a sorting thread pool 131.

[0075] Among them, the distribution thread pool 130 is used to classify the various original messages and then distribute those belonging to the same business process together.

[0076] The sorting thread pool 131 is used to sort the original messages of the same business process according to the message state dependency rules, and then feed the ordered messages back to the message middleware 11 so that the subscriber 11 can consume them.

[0077] Optionally, based on Figure 4 The demonstrated message sorting device, below is one possible implementation of the message sorting method, specifically... Figure 5 This is a flowchart illustrating a message sorting method provided in an embodiment of the present invention. See also... Figure 5The method includes:

[0078] Step 200: The distribution thread pool retrieves the original messages from each subscribed message queue of the message middleware.

[0079] Step 201: The distribution thread pool assigns the original messages of the same business process to the unsorted original message queue of the same distribution thread.

[0080] Step 202: The worker threads of the sorting thread pool read the original messages from the corresponding unsorted original message queue and store them in the thread's local cache set.

[0081] Step 203: The worker thread determines the sendability of messages in the cache set based on the message state dependency rules.

[0082] The message state dependency rule represents the dependency relationship between different messages in the same business process. If the sending condition is met, proceed to step 204; otherwise, proceed to step 205.

[0083] Step 204: Send the corresponding message as an ordered message to the subscription queue.

[0084] Step 205: Retain the corresponding message in the cache set.

[0085] The message sorting method provided in this invention obtains original messages through a distribution thread pool and assigns messages of the same business process to the same queue to be sorted. The sorting thread pool worker threads read messages and store them in a thread-local cache set. Based on rules representing message dependencies within the business process, sendability is determined; messages that meet the conditions are sent to the subscription queue, while those that do not are retained in the cache. This mechanism effectively solves the problem of out-of-order messages of the same business process caused by multiple switches and network latency in message middleware, avoiding data inconsistency and business anomalies. A unified sorting logic replaces redundant development on the subscriber side, reducing system complexity. Through thread pool division of labor, local cache storage, and caching strategies for messages that do not meet the conditions, interaction overhead is reduced. In high-frequency transaction scenarios, it balances message ordering and low latency requirements, improving processing throughput, real-time performance, and resource utilization under high concurrency. Simultaneously, the rules are independent of the core process, enhancing business adaptability flexibility.

[0086] Optionally, for the distribution thread pool, to ensure that the original messages of the same business process can be distributed to a single distribution thread, and that the distribution threads can allocate original messages based on resource balancing, a mechanism for allocating original messages is provided below. Figure 4 On this basis, Figure 6 A schematic diagram of another message sorting device provided in an embodiment of the present invention is shown below. Figure 6The distribution thread pool also includes a distributor 130a, which is used to parse the raw message in order to obtain information related to the message ordering mechanism of this application.

[0087] Optionally, in Figure 6 Based on the architecture shown, a dispatcher-based distribution mechanism is provided below. Specifically, in Figure 5 On this basis, Figure 7 A flowchart illustrating another message sorting method provided in an embodiment of the present invention is shown below. Figure 7 Step 201 includes:

[0088] Step 201-1: The distributor parses each original message to obtain the business primary key, status identifier, current processable status range, data content, and attribute information corresponding to each original message.

[0089] The business primary key is used to uniquely identify the business process corresponding to the original message. The current processable state range indicates the range of hierarchical states that the target business process can currently process.

[0090] Optionally, the next status value to be sent can be defined by specifying "status value already sent" and "status value to be sent next".

[0091] Step 201-2: The distributor calculates the hash value corresponding to each original message based on each business primary key.

[0092] Step 201-3: The dispatcher uses the hash value corresponding to each original message to assign the same business process to the unsorted original message queue of the same dispatch thread.

[0093] Optionally, the dispatcher performs hash calculations based on each business primary key, and then maps the hash to a fixed dispatch thread. Specifically, an initial hash value is first calculated, and then bit-level perturbation is used to provide the core design idea of ​​uniform distribution and avalanche effect. The hash function in this application improves the avalanche effect of hashing through multiple rounds of bit operation perturbation. A code example is shown below:

[0094] sizethash = hasher(key);

[0095] hash^=hash>>16;

[0096] hash*=x85ebca6b;

[0097] hash^=hash>>13;

[0098] / / 1. Get the initial hash value

[0099] / / 2. High and low bit mixing (right shift 16 bits XOR)

[0100] / / 3. Multiply by a large prime number (similar to a mixed constant like MurmurHash3)

[0101] / / 4. Another high-level diffusion

[0102] returnstaticcast <int>(hash%numthreads);

[0103] As can be seen, the hash function implemented in this application solves the problem of unbalanced load in a multi-threaded environment without sacrificing performance through a lightweight but efficient hash perturbation strategy.

[0104] Optionally, for the sorting thread pool, to further improve the efficiency and accuracy of sorting, a sorting mechanism that further decouples responsibilities is provided below. Specifically, in Figure 4 On this basis, Figure 8 A schematic diagram of another message sorting device provided in an embodiment of the present invention is shown below. Figure 8 In the sorting thread pool 131, for each worker thread, the cache set in the above example is implemented based on the first-level cache 131a and the second-level cache 131b. The core idea is to set up the first-level cache 131a and the second-level cache 131b, where the first-level cache 131a is responsible for maintaining information related to "state tracking" and the second-level cache 131b is used to complete "data retention".

[0105] Optionally, based on the aforementioned "first-level cache" and "second-level cache" storage mechanisms, the following provides a possible implementation method for storing the original message. Specifically, in Figure 7 On this basis, Figure 9 A flowchart illustrating another message sorting method provided in an embodiment of the present invention is shown below. Figure 9 Step 202 includes:

[0106] Step 202-1: Obtain the business primary key, current processable state range, data content, and attribute information corresponding to each original message in the unsorted original message queue.

[0107] Step 202-2: Store the business primary key and the current processable state range in the first-level cache.

[0108] Optionally, the data structure in this first-level cache (cached_obj) is shown in the following example:

[0109] structccached_obj

[0110] {

[0111] std::string_key; / / Primary key field for business data

[0112] std::string_send_status_value; / / Status value of sent data, initially set to the initial value.

[0113] std::string_next_status_value; / / The next status value to be sent

[0114] std::string_last_send_time; / / Latest send time

[0115] std::double_t_entrust_amount; / / Number of delegates for the same business process

[0116] std::double_t_realdeal_amount; / / Number of transactions in the same business process

[0117] std::vector_vt_json_data; / / Caches message data with the same primary key but different states.

[0118] };

[0119] The `std::vector_vt_json_data;` parameter can be implemented by maintaining a list of original messages, where each item points to different states of data content in the second-level cache under the same primary key. Additionally, `order quantity` and `transaction quantity` can serve as constraints for determining whether to perform cache cleanup for the same business process.

[0120] Optionally, in this example, the currently processable state range includes the state values ​​that have been sent (initially set to the initial value) and the next state value to be sent.

[0121] Step 202-3: Store the business primary key, data content, and attribute information in the second-level cache.

[0122] Optionally, the data structure in this second-level cache is shown in the following example:

[0123] structccached_json_data

[0124] {

[0125] std::string_key; / / Primary key field for business data

[0126] std::string_status; / / Status identifier of the message corresponding to the current record

[0127] std::string_is_ending; / / Whether it's the ending state (attribute information)

[0128] std::string_json_data;

[0129] std::string_is_keep_status; / / Preserve the current state (attribute information)

[0130] std::string_restore_value; / Restores the order to the specified state (attribute information) of the next processing level after receiving a rollback message when the order has been closed.

[0131] std::string_busin_amount_field; [Field name corresponding to the transaction quantity; different fields may be stored for different types of messages] / / Total transaction quantity field. Ends when the total transaction quantity of a single order is greater than or equal to the order quantity (attribute information).

[0132] std::string_entrust_amount_field; [Field name corresponding to the number of delegates; different fields may be stored for different message types] / / Delegation quantity field: The number of delegates in the original delegate (attribute information)

[0133] std::double_t_busin_amount; [Transaction volume of this order] / / Total number of transactions. The transaction ends when the total number of transactions for a single order is greater than or equal to the order quantity (attribute information).

[0134] std::double_t_entrust_amount; [Total number of delegates, redundancy] / / Number of delegates: Original number of delegates (attribute information)

[0135] std::string_is_realdeal; / / Marks whether a transaction has been completed.

[0136] std::uint64_t_recv_timestamp; / / Received timestamps are sent in chronological order during batch processing.

[0137] std::string_s_event_time; / / Event occurrence time

[0138] };

[0139] Optionally, for the above-mentioned two-level caching mode, this application can adopt a "caching combined with batch decision-making" design pattern, which differs from the conventional approach of "instantaneous judgment and sending" in the following ways:

[0140] The conventional approach is to directly determine the status, construct the response, and call the sending interface within the message callback function. The receiving path handles multiple responsibilities, including business logic, status checks, and I / O transmission.

[0141] In the receiving phase of this application, the system is only responsible for archiving the original messages to the thread-local second-level cache (ccached_json_data) according to the business primary key. In the processing phase, the system independently scans the cache in a loop, and makes atomic decisions and sends messages based on the complete state, such as the sent state and next state in the first-level cache (cached_obj). This clearly separates "data retention" from "state tracking", conforms to the single responsibility principle, and improves module cohesion.

[0142] Below Figure 8 Based on the architecture shown, a possible implementation method for using a sorting thread pool to perform message sorting is provided. Specifically, in Figure 9 On this basis, Figure 10 A flowchart illustrating another message sorting method provided in an embodiment of the present invention is shown below. Figure 10 Step 203 includes:

[0143] Step 203-1: The worker thread obtains the current processable state range of the target business process from the first-level cache.

[0144] Optionally, the worker thread retrieves subscribed raw messages in batches from an internal queue and executes CPU-intensive message sorting logic based on state identifiers, including: multiple worker threads (such as worker threads 1 to n), each worker thread independently processing one or more sets of raw messages.

[0145] For CPU-intensive sorting thread pools, the tasks executed by the worker threads need to continuously occupy computing resources. Therefore, in order to avoid unnecessary thread switching, the initial number of threads can be set to be equal to the number of CPU cores, thereby improving the efficiency of each CPU core and reducing congestion.

[0146] Optionally, each worker thread maintains a thread-local cache list of messages to be sent (cached_orderlines_datas) to temporarily store raw messages to be processed, ensuring the order of messages within the same group.

[0147] Step 203-2: The worker thread obtains the status identifier and attribute information of the target message in the second-level cache.

[0148] Optionally, the worker thread traverses the second-level cache (cached_json_data), extracts the business primary key (such as the order number) according to the pre-configuration, parses the target message, and extracts the business primary key (such as the order number), the status identifier of the current target message, and attribute information (such as the number of orders, the total number of transactions, and the fields that maintain the current status) according to the pre-configured business dataset index.

[0149] Step 203-3: The worker thread determines whether the status identifier matches the current range of processable statuses based on the different types of attribute information.

[0150] Optionally, based on the state transition topology in the pre-configured message state dependency rules ( <status>Determine whether the message meets the "can be sent" condition, that is, whether it matches the current processable state range; the message state dependency rule can be composed of "attribute information" and "state identifier". For the judgment in step 203-3, if yes, then execute step 204-1; if no, then execute step 205-1.

[0151] Optionally, for this message state dependency rule, it can be achieved through... <status>Each of the following <value>The sequence of elements defines the flow path of business events and the various levels that a business process (such as a work order) goes through within its complete lifecycle. An example of its rules is as follows:

[0152] <status>

[0153] <!--The start value of the status field is_start must have exactly one, and the end value does not need to be configured (configured in the corresponding is_ending field), and the status automatically depends on the previous one-->

[0154] <value isstart="1" note="Entrustment issued (1)">1< / status> < / value>

[0155] <valuenote="After the order is placed, there are two states: cancelled order (3) (terminated state) and order confirmation (4). For internal cancellation, it is directly sent">3; 4

[0156] <valuenote="After the order is confirmed, the corresponding order cancellation may occur: order cancellation (2), execution (7) (multiple terminal states)">2; 7

[0157] <valuenote="After the order is cancelled, the following may occur: cancelled order (5) (terminated state), cancelled order rejection (6) (after rejection, it reverts to 4 - order confirmation), execution (7) (multiple terminal states)">5; 6; 7

[0158] < / status>

[0159] Step 204-1: Send the target message as an ordered message to the subscription queue and update the current processable state range.

[0160] Optionally, if the "sendable" condition is met, the ordered message is sent to the target switch maintained by message middleware 11 as in the example above, and the subscriber can obtain the ordered message through the subscription queue of each target switch.

[0161] Step 205-1: Keep the target message in the cache set.

[0162] Optionally, for step 203-3 above, the "attribute information" provided in this application is used to indicate, for example... Figure 2 , Figure 3 The diagram illustrates the possible message dependencies involved in various business events. Examples of different dependency scenarios are provided below. Specifically, in... Figure 10 On this basis, Figure 11 A flowchart illustrating another message sorting method provided in an embodiment of the present invention is shown below. Figure 11 Step 204-1 includes:

[0163] Step 204-1a: If the attribute information is the initial state and the state identifier matches the current processable state range, then send the target message as an ordered message to the subscription queue and update the current processable state range.

[0164] Optionally, if the state sequence formed by the state identifiers corresponding to the target message has one and only one attribute information with is_start="1", then this is taken as the starting state of the business entity. The processing of all subsequent states is based on the reception and transmission of this state.

[0165] Step 204-1b: If the attribute information is in a normal state and the state identifier matches the current processable state range, then send the target message as an ordered message to the subscription queue and update the current processable state range.

[0166] Optionally, if the attribute information is not marked with: is_start="1" and is_ending="0" and there is no fallback state related with: restore_value="*;*"; (* is the specific status identifier), then the attribute information can be considered to be a normal state. In this case, if the status identifier is: status="3" and the current range of processable states is: next_status_value="3;4", then the status identifier is considered to match the current range of processable states.

[0167] However, if the status identifier is status=2 and the current range of processesable statuses is next_status_value="3;4", then the status identifier does not match the current range of processesable statuses.

[0168] It should be noted that in `next_status_value="3;4"`, "3" and "4" are the status indicators that can be processed at the corresponding level. For example, with... Figure 3 For example, for L2, the status identifier of message 3 is "3" and the status identifier of message 5 is "4".

[0169] Step 204-1c: If the attribute information is in a rollback state and the state identifier matches the current processable state range, then the target message is sent to the subscription queue as an ordered message, and the current processable state range is rolled back to the previous state.

[0170] Optionally, if the status identifier is status=6 and the attribute information is restore_value="2", that is, to fall back to the message with status identifier status="2", the current processable status range is next_status_value="5;6", and the sent status value is send_status_value="4", then first determine whether the status identifier matches the current processable status range: status="6" matches next_status_value="5;6".

[0171] At this point, the current processable status range: next_status_value="5;6" will be rolled back to next_status_value="2".

[0172] Step 204-1d: If the attribute information is in a terminated state and the state identifier matches the current processable state range, if the previous state identifier in the current processable state range is determined to be sent and has a termination identifier based on the state identifier, then the target message is sent to the subscription queue as an ordered message, and the secondary cache is cleaned up.

[0173] Optionally, if the attribute information is: is_ending="1", which is the termination state, then the status identifier of the target message is: status=3, and the current processable status range is: next_status_value="3;4", then the target message is sent to the subscription queue and the second-level cache is cleaned up.

[0174] Optionally, for business processes that are already in a "terminated state," the utilization efficiency of storage resources can be improved by clearing the cache. Specifically, in Figure 11 On this basis, Figure 12 A flowchart illustrating another message sorting method provided in an embodiment of the present invention is shown below. Figure 12 Step 204-1d includes:

[0175] Step 204-1d-1: Send the target message as an ordered message to the subscription queue.

[0176] Step 204-1d-2: Determine whether the attribute information of the target message meets the cleanup constraints.

[0177] If the condition is met, then step 204-1d-3 is executed; otherwise, the process returns to step 203 as described in the preceding example.

[0178] Step 204-1d-3: Clean up the cached data of the target business process corresponding to the target message in the secondary cache.

[0179] Optionally, for cleanup constraints, refer to the example of the first-level cache mentioned above, where the number of orders (std::double_t_entrust_amount) and the number of transactions (std::double_t_realdeal_amount) maintained by the cache are used to confirm whether the attribute information of the target message meets the cleanup constraints.

[0180] For example, if the message is "Termination status of the transaction (e.g., status=7)": when the first-level cache _realdeal_amount (cumulative transaction quantity) ≥ _entrust_amount (order quantity), the cleanup constraint is met, and the cache is marked for cleanup; another example is a non-transactional final state (e.g., status=3 / 5 / 6): there is no need to verify the transaction quantity, only to mark the final state and meet the time cleanup constraint; another example is a possible implementation of cache cleanup triggering: after the cleanup constraint is met, the cache cleanup thread will delete the first-level cache and second-level cache of the order after a preset time (e.g., 1 hour).

[0181] To better illustrate the relationship between the business processes, business events, messages, and the processing mechanisms described in the above examples, please first refer to Scenario 1: Securities Order Lifecycle Processing Flow 1. Specifically, Figure 13 For another example diagram illustrating the dependency relationship provided in this embodiment of the invention, see [link to diagram]. Figure 13 This business process revolves around the business lifecycle of a "single order," with "order placement → order confirmation → order operation (cancellation / completion) → termination / rollback status" as the main thread. It progresses according to a hierarchical dependency rule of L0→L1→L2→L3, and each business event triggers the orderly sending of corresponding messages, as detailed below:

[0182] Step 1: L0 level (process start), delegated event triggers the sending of the start message.

[0183] Business event: The upstream publisher initiates message 1 "Delegation issued", generating a delegation order (a unique delegate primary key).

[0184] Message processing: The architecture of this application receives message 1 with message_type=4001 (status=1), identifies the attribute information of message 1, and confirms that it is the L0 level starting state (no prerequisites).

[0185] Action to execute: Immediately send message 1 to the target exchange's subscription queue (destExchange) to complete the L0 level process loop, and update the first-level cache send_status_value="1" and next_status_value="3;4" (open L1 level message processing).

[0186] Step 2: L1 level (delegated verification branch), choose between termination status and process advancement.

[0187] Branch A: Order cancellation (terminated).

[0188] Business event: Order verification fails (e.g., insufficient funds, abnormal target), triggering the "order cancellation" event.

[0189] Message processing: The system receives message 3 with message_type=4004 (status=3, is_ending="1"), and the state machine recognizes message 3 as the final branch of the L1 level (which depends on the L0 level to complete).

[0190] Action to execute: Send the message to the target exchange's subscription queue (destExchange), mark the corresponding order as terminated, and trigger first-level / second-level cache cleanup (without advancing to subsequent levels).

[0191] Branch B: Delegation Confirmation (Process Progress).

[0192] Business event: The order verification passes and the "order confirmation" event is triggered.

[0193] Message processing: The system receives message 4 with message_type=4005 (status=4) and identifies it as a non-terminating state branch at the L1 level (which depends on the L0 level to complete).

[0194] Action: Send the message to the target exchange's subscription queue (destExchange), update the first-level cache with send_status_value="4" and next_status_value="2;7" in the current processable state range (the process advances to the L2 level, enabling L2 level message processing).

[0195] Step 3: L2 level (delegated operation branch), cancellation event trigger message sending.

[0196] Business event: When a user initiates a "cancel order" operation, the "cancel order" event is triggered.

[0197] Message processing: The system receives message 2 with message_type=4003 (status=2) and identifies it as an L2 level branch (relying on L1 level delegation for confirmation of completion).

[0198] Action: Send message 2 to the target exchange's subscription queue (destExchange), update the first-level cache with send_status_value="2" and next_status_value="5;6" in the current processable state range (progressing the process to the L3 level).

[0199] Step 4: L3 level (cancellation result branch), the cancellation event triggers a state rollback.

[0200] Business event: The order cancellation operation failed, triggering the "Order Cancellation" event;

[0201] Message processing: The system receives message 6 with message_type=4007 (status identifier=6, restore_value="2;7") and identifies message 6 as an L3-level rollback branch (relying on L2-level order cancellation to complete).

[0202] Perform the following actions:

[0203] Send message 6 to the target exchange's subscription queue (destExchange).

[0204] Execution status rollback: Roll back the next_status_value in the current processable state range of the first-level cache from "5;6" at the L3 level to "2;7" at the L2 level (correct the original expression "2;4" to the consistent "2;7");

[0205] Enable L2 level message reception: Allow the system to continue receiving and sorting messages with status=2 (order cancellation) and status=7 (transaction completed);

[0206] Cache update: The send_status_value in the current processable status range is updated to "6", retaining the order process (not yet finalized).

[0207] Step 5: After rolling back to the L2 level, the transaction event is triggered and finalized.

[0208] Business event: The order is matched and executed, triggering the "order execution" event.

[0209] Message processing: The system receives message 7 with message_type=5001 (status=7) and identifies message 7 as an L2 level final state branch (depending on the open state after L2 level fallback).

[0210] Actions: Send message 7 to the target exchange's subscription queue (destExchange), verify that the number of transactions in the first-level cache (realdeal_amount) is greater than or equal to the number of orders (entrust_amount), mark the order as terminated, trigger cache cleanup, and complete the entire closed loop.

[0211] In summary, the hierarchical dependencies in this example are as follows: L1 level messages (3 / 4) depend on L0 level (1) to complete, L2 level messages (2 / 7) depend on L1 level (4) to complete, and L3 level messages (6) depend on L2 level (2) to complete. Rollback operations are only allowed to roll back to the level (L2) that the process has reached. Final state rules: L1 level state 3 (cancelled order) and L2 level state 7 (completed transaction) are terminated states, triggering cache cleanup. Non-terminated state messages only advance the process level and do not terminate the business process. Rollback rules: The rollback operation of L3 level state 6 is based on restore_value and can only roll back to the historical next_status_value (L2 level "2;7") to ensure that the rollback conforms to the business process trajectory.

[0212] Optionally, see Scenario 2: Securities Order Lifecycle Processing Flow. Specifically, Figure 14 For another example diagram illustrating the dependency relationship provided in this embodiment of the invention, see [link to diagram]. Figure 14 Securities order lifecycle processing flow 2. This business process revolves around the business lifecycle of a "single order," with "order placement → order confirmation → order execution → termination status" as the main thread. It proceeds according to the hierarchical dependency rules of L0→L1→L2, and each business event triggers the orderly sending of corresponding messages, as detailed below:

[0213] Step 1: L0 level (process start), delegated event triggers the sending of the start message.

[0214] Business event: The upstream publisher initiates message 1 "Delegation issued", generating a delegation order (a unique delegate primary key).

[0215] Message processing: The architecture of this application receives message 1 with message_type=4001 (status=1), identifies the attribute information of message 1, and confirms that it is the L0 level starting state (no prerequisites).

[0216] Action: Immediately send message 1 to the target exchange's subscription queue (destExchange), completing the L0 level process loop, and update the first-level cache _send_status_value="1" and _next_status_value="3;4" (open L1 level message processing).

[0217] Step 2: L1 level (delegated verification branch), choose between termination status and process advancement.

[0218] Branch A: Order cancellation (terminated).

[0219] Business event: Order verification fails (e.g., insufficient funds, abnormal target), triggering the "order cancellation" event.

[0220] Message processing: The system receives message 3 with message_type=4004 (status=3, is_ending="1"), and the state machine recognizes message 3 as the final branch of the L1 level (which depends on the L0 level to complete).

[0221] Action to execute: Send the message to the target exchange's subscription queue (destExchange), mark the corresponding order as terminated, and trigger first-level / second-level cache cleanup (without advancing to subsequent levels).

[0222] Branch B: Delegation Confirmation (Process Progress).

[0223] Business event: The order verification passes and the "order confirmation" event is triggered.

[0224] Message processing: The system receives message 4 with message_type=4005 (status=4) and identifies it as a non-terminating state branch at the L1 level (which depends on the L0 level to complete).

[0225] Action: Send the message to the target exchange's subscription queue (destExchange), update the first-level cache with send_status_value="4" and next_status_value="2;7" in the current processable state range (the process advances to the L2 level, enabling L2 level message processing).

[0226] Step 3: L2 level (order execution branch), the transaction event is triggered and finalized.

[0227] Business event: The order is matched and executed, triggering the "order execution" event.

[0228] Message processing: The system receives message 7 with message_type=5001 (status=7) and identifies message 7 as an L2 level final state branch (relying on L1 level delegation confirmation of completion).

[0229] Perform the following actions:

[0230] Send message 7 to the target exchange's subscription queue (destExchange).

[0231] Verify the final state condition of the transaction: If the message is a transaction message (is_realdeal), then calculate whether the number of transactions in the first-level cache (realdeal_amount) has reached the number of orders (entrust_amount).

[0232] Cache cleanup for terminated status: If the number of transactions is greater than or equal to the number of orders, the order is marked as terminated, triggering the cleanup of the first-level and second-level caches to complete the closed loop of the entire process; if not, the cache is retained, and the order is re-verified after subsequent transaction messages are added and accumulated.

[0233] In summary, the hierarchical dependencies in this example are as follows: L1 level messages (3 / 4) depend on L0 level (1) to complete, and L2 level (7) depends on L1 level (4) to complete; final state rules: L1 level state 3 (cancelled order) and L2 level state 7 (completed transaction, which requires the number of completed transactions to be greater than or equal to the number of orders) are the termination states, triggering cache cleanup; non-termination state messages only advance the process level and do not terminate the business process; final state rules for completed transactions: the termination state of L2 level state 7 must be based on the is_realdeal identifier, combined with the numerical relationship between the number of orders and the number of completed transactions in the first-level cache, to ensure that the final state conforms to the actual business transaction logic.

[0234] Optionally, in order to perform the steps shown in the above examples and achieve the corresponding technical effects, this application also provides a message sorting apparatus. Optionally, Figure 15 A schematic diagram of another message sorting device provided in an embodiment of the present invention is shown below. Figure 15 The message sorting device includes a distribution thread pool 130 and a sorting thread pool 131.

[0235] The distribution thread pool 130 is used to retrieve raw messages from each subscribed message queue of the message middleware; and to distribute raw messages of the same business process to the unordered raw message queue of the same distribution thread.

[0236] The sorting thread pool 131 is used to read original messages from the corresponding unsorted original message queue through worker threads and store them in the thread-local cache set; based on the message state dependency rules, the sendability of messages in the cache set is determined; the message state dependency rules represent the dependency relationship between different messages in the same business process; if the sending condition is met, the corresponding message is sent to the subscription queue as an ordered message; if the sending condition is not met, the corresponding message is kept in the cache set.

[0237] Optionally, the worker threads of the sorting thread pool 131 are specifically used for: obtaining the current processable state range of the target business process in the first-level cache 131a; the current processable state range is used to indicate the hierarchical state range that the target business process can currently process; obtaining the state identifier and attribute information corresponding to the target message in the second-level cache 131b; determining whether the state identifier matches the current processable state range based on the different types of attribute information; if yes, sending the target message as an ordered message to the subscription queue and updating the current processable state range; if no, keeping the target message in the cache set.

[0238] Optionally, the worker threads of the sorting thread pool 131 are specifically used for: if the attribute information is in the starting state and the state identifier matches the current processable state range, then sending the target message as an ordered message to the subscription queue and updating the current processable state range; if the attribute information is in the normal state and the state identifier matches the current processable state range, then sending the target message as an ordered message to the subscription queue and updating the current processable state range; if the attribute information is in the fallback state and the state identifier matches the current processable state range, then sending the target message as an ordered message to the subscription queue and falling back the current processable state range to the previous state; if the attribute information is in the termination state and the state identifier matches the current processable state range, and if it is determined from the state identifier that the previous state identifier in the current processable state range has been sent and has a termination identifier, then sending the target message as an ordered message to the subscription queue and clearing the second-level cache.

[0239] Optionally, the worker threads of the sorting thread pool 131 are specifically used for: sending the target message as an ordered message to the subscription queue; determining whether the attribute information of the target message meets the cleanup constraints; and if so, cleaning up the cached data of the target business process corresponding to the target message in the second-level cache.

[0240] See also Figure 15 The distribution thread pool 130 has a distributor 130a.

[0241] Distributor 130a is specifically used to parse each original message to obtain the business primary key, status identifier, current processable status range, data content, and attribute information corresponding to each original message; the business primary key is used to uniquely identify the business process corresponding to the original message; the hash value corresponding to each original message is calculated based on each business primary key; and the same business process is assigned to the unsorted original message queue of the same distribution thread using the hash value corresponding to each original message.

[0242] Optionally, the worker threads of the sorting thread pool 131 are specifically used to: obtain the business primary key, current processable state range, data content, and attribute information corresponding to each original message in the original message queue to be sorted; store the business primary key and current processable state range in the first-level cache 131a; and store the business primary key, state identifier, data content, and attribute information in the second-level cache 131b.

[0243] Optionally, to illustrate the various functions involved in the above examples, a deployment example of a message sorting device is provided below for detailed explanation. Specifically, Figure 16 A schematic diagram of another message sorting device provided in an embodiment of the present invention is shown below. Figure 16 This architecture includes publisher 10, message middleware 11, and multiple subscribers, such as... Figure 16 The subscribers 12a, 12b, and 12c shown, as well as the message sorting device shown in the example above.

[0244] Among them, publisher 10: the source of messages (such as the order placement and transaction business systems of securities systems), sends raw messages to multiple "source switches"; message middleware 11: responsible for message storage and forwarding, including two types of components: "source switches" and "target switches"; message sorting device: the core of the architecture (the middle area in the figure), including modules such as "unified subscription unit 130b, distributor 130a, distribution thread pool 130, and sorting thread pool 131", which is the key to realizing message ordering; subscriber 12: the receiver of messages (such as downstream clearing and risk control systems), obtains ordered messages from the "target switch".

[0245] For example, publisher 10 sends the original message to multiple source switches (source switches 1~n), each source switch corresponds to a "subscription message queue" (subscription message queue 1~n), and message middleware 11 temporarily stores the original message in these queues, waiting for subsequent processing.

[0246] Optionally, subscriptions can be grouped by business function using an external configuration file (such as hix_msg_orderliness_config.xml). Message state dependency rules can be defined within each group. The core of this mechanism lies in defining a set of state-driven message state dependency rules for specific business scenarios (such as "bulk fixed income" orders) through a structured configuration file. This mechanism maps the business semantics of messages (such as order placement, cancellation, and transaction) to predefined state identifier values, and based on hierarchical state dependencies and explicit state transition semantics, ensures that downstream systems always receive ordered messages in the correct business process sequence.

[0247] To improve system throughput and ensure the real-time performance and stability of message processing, this application adopts a multi-stage asynchronous pipeline architecture, which divides the message processing flow into a subscription, reception and distribution stage (distribution thread pool) and a state sorting stage (sorting thread pool), and allocates independent thread pool resources to each stage to achieve logical decoupling of computing tasks and runtime resource isolation.

[0248] by<subname="sub.hix.orderliness.entrusts.bulkfixed"> Taking the defined "bulk fixed income" business as an example, its configuration includes three key parts: business grouping ( )、状态流转拓扑（ <status> ）与消息-状态映射规则（ <exchange> ）。配置规则的关键要素包括：

[0249] 可选地，业务分组( )可以涉及的要素项：

[0250] 1）订阅方名称（name）：为空则系统自动生成，订阅方前缀以及交换机名称。

[0251] 2）键前缀（key_prefix）起作用为定义各订阅方不能重复，防止不同业务流程的关键字段相同并且被分配到相同的排序线程池的工作线程处理。

[0252] 3）目标交换机（destExchange），订阅方收到有序消息并序列化后要发往的目标交换机。

[0253] 4）目标主题名称（destTopicName），发往的目标交换机时使用的路由键（routing-key）。

[0254] 可选地，消息-状态映射规则（ <exchange> ）可以涉及的要素项：

[0255] 1）业务主键的字段（key_fields）：用于唯一标识同一业务流程（如委托单号）。

[0256] 2）状态标识的取值序列（status_value）：定义该类型的业务事件下，消息所代表的业务状态的合法流转顺序，如：委托下达→委托确认（→委托撤单→委托撤成 / 委托撤废→委托成交。

[0257] 3）模型编号（model_no）与事件（message_type）类型：关联业务模型，用于精确匹配消息。根据模型编号和事件类型，获取源交换机与目标交换机：指定从哪些源交换机订阅消息，并将排序后的消息发布到哪个目标交换机。

[0258] 4）数据集索引（dataset_idx）消息推送是多数据集业务数据在第2个数据集上，索引对应1。

[0259] 5）状态保持字段（keep_status_field）保持当前状态的字段如部成，当收到对应消息，检查对应状态保持字段中的值和配置的状态保持字段的值相同时，虽然收到此条消息，状态不会向后移动。

[0260] 6）状态保持字段的值（keep_status_field_value）保持当前状态的字段值。

[0261] 7）状态机回退到指定状态（restore_value）单子由已终结时，收到回撤消息，回退到下一等处理的指定状态。

[0262] 8）成交数量（busin_amount_field）总成交数量字段，一笔委托的总成交数量>=委托数量时结束。

[0263] 9）委托数量（entrust_amount_filed）委托数量字段，原委托的委托数量。

[0264] 10）是否成交消息（is_realdeal）标记是否成交消息，配合是否结束消息，处理多笔部成。

[0265] 11）是否结束消息（is_ending）标记是否是结束消息，结束消息可能是：撤成、成交、废单等消息。

[0266] 继续参见 图16，统一订阅单元130b先获取所有源交换机的各个原始消息。分发器130a解析原始消息的"业务主键”（比如委托单号）等信息，将原始消息分配到对应的分发线程（分发线程1~n）。每个分发线程对应一个队列，暂存同主键的原始消息（比如同一委托单的"委托下达、成交”消息会被分到同一个队列），避免不同业务的消息混淆。

[0267] 排序线程池131是实现有序化的核心，包含多个"工作线程”（工作线程1~n），每个工作线程对应一组一级缓存与二级缓存。其中，一级缓存：存储"业务主键”与"当前可处理状态范围”（比如L1层级允许处理状态3、4）等信息，是排序的"规则依据”（对应之前提到的ccached_obj）；二级缓存：存储"业务主键”、"数据内容”以及"属性信息”，并标记各个消息的"状态标识”（比如消息1对应状态1、消息2对应状态2）（对应之前提到的ccached_json_data）。

[0268] 参见上述示例可知工作线程会基于"一级缓存的状态范围”，对二级缓存中的消息做有序性判定：只有消息的"状态标识”属于"当前可处理状态范围”（比如状态1属于L0层级范围），才会被判定为"可发送”，进而作为有序消息发送至对应目标交换机的订阅队列中。判定通过的消息，会被标记为"待发送”，等待后续转发到目标交换机。而判定不可发送的消息，则继续缓存在二级缓存中。

[0269] 排序后的消息被发送至多个目标交换机（目标交换机1~n），每个目标交换机对应一个"订阅队列”（订阅队列1~n），订阅方12（订阅方12a~12c）从这些队列中获取有序消息，此时队列中的有序消息已按业务逻辑排序（比如图中"订阅队列2”的消息1在消息2之前，符合"先委托、后成交”的逻辑）。

[0270] 上述架构，通过"按业务主键分发+缓存记录状态规则+线程池并行排序”的设计，解决了两个核心问题：1）消息乱序：通过一级缓存的"状态范围”和二级缓存的"状态标识”，确保消息按业务层级（L0→L1→L2）发送；2）高并发处理：用多个分发线程、工作线程并行处理不同业务主键的消息，兼顾"有序性”和"高吞吐量”。

[0271] 本发明实施例还提供一种电子设备，其可以执行本发明实施例上述全部示例的步骤，以实现对应的技术效果。具体的， 图17为本发明实施例提供的一种电子设备的结构示意图，参见 图17，该电子设备30，包括：存储器301、处理器300；

[0272] 存储器301，用于存储一个或多个程序；

[0273] 处理器300；

[0274] 当一个或多个程序被处理器执行时，当该电子设备30用于执行上述各个方法示例所示的步骤时，其可以实现各个步骤及对应技术效果。

[0275] 在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和 / 或流程图中的每个方框、以及框图和 / 或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

[0276] 另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

[0277] 功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以程序产品的形式体现出来，该程序产品存储在一个计算机可读存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，RandomAccessMemory）、磁碟或者光盘等各种可以存储程序代码的介质。

[0278] 以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

[0279] 对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。 < / exchange> < / exchange> < / status> < / status> < / int>

Claims

1. A message sorting method, characterized in that, include: The distribution thread pool retrieves raw messages from each subscribed message queue of the message middleware; The distribution thread pool assigns the original messages of the same business process to the unsorted original message queue of the same distribution thread; The worker threads of the sorting thread pool read the original messages from the corresponding unsorted original message queue and store them in the thread's local cache set; The worker thread obtains the current processable state range of the target business process from the first-level cache; the current processable state range is used to indicate the hierarchical state range that the target business process can currently process; The worker thread obtains the status identifier and attribute information of the target message in the second-level cache; The worker thread determines whether the status identifier matches the current processable status range based on the different types of the attribute information; the current processable status range is used to indicate the range of hierarchical statuses that the target business process can currently process. If so, the target message is sent to the subscription queue as an ordered message, and the current processable state range is updated; If not, the target message is retained in the cache set.

2. The method according to claim 1, characterized in that, The step of sending the target message as the ordered message to the subscription queue and updating the current processable state range includes: If the attribute information is in the initial state and the state identifier matches the current processable state range, then the target message is sent to the subscription queue as the ordered message, and the current processable state range is updated. If the attribute information is in a normal state, and the state identifier matches the current processable state range, then the target message is sent to the subscription queue as the ordered message, and the current processable state range is updated. If the attribute information is in a rollback state, and the state identifier matches the current processable state range, then the target message is sent to the subscription queue as the ordered message, and the current processable state range is rolled back to the previous state. If the attribute information is in a terminated state, and the state identifier matches the current processable state range, and if the previous state identifier in the current processable state range is determined to be sent and has a termination identifier based on the state identifier, then the target message is sent to the subscription queue as the ordered message, and the secondary cache is cleaned up.

3. The method according to claim 2, characterized in that, The steps of sending the target message as the ordered message to the subscription queue and clearing the secondary cache include: The target message is sent to the subscription queue as an ordered message; Determine whether the attribute information of the target message meets the cleanup constraints; If the conditions are met, the cached data of the target business process corresponding to the target message in the secondary cache will be cleaned up.

4. The method according to claim 1, characterized in that, The step of the distribution thread pool assigning raw messages of the same business process to the unordered raw message queue of the same distribution thread, wherein the distribution thread pool has a dispatcher, includes: The distributor parses each original message to obtain the business primary key, status identifier, current processable status range, data content, and attribute information corresponding to each original message; the business primary key is used to uniquely identify the business process of the corresponding original message; The distributor calculates the hash value corresponding to each original message based on each of the business primary keys; The distributor uses the hash value corresponding to each original message to assign the same business process to the unsorted original message queue of the same distribution thread.

5. The method according to claim 4, characterized in that, The step of the worker threads of the sorting thread pool reading raw messages from the corresponding raw message queue to be sorted and storing them in the thread-local cache set includes: Obtain the business primary key, current processable state range, data content, and attribute information corresponding to each original message in the unsorted original message queue; Store the business primary key and the current processable state range in the first-level cache; The business primary key, the status identifier, the data content, and the attribute information are stored in the second-level cache.

6. A message sorting device, characterized in that, include: The distribution thread pool is used to retrieve raw messages from each subscribed message queue of the message middleware; and to distribute raw messages of the same business process to the unordered raw message queue of the same distribution thread. A sorting thread pool is used to read raw messages from the corresponding raw message queue to be sorted through worker threads and store them in a local cache set of the thread; obtain the current processable state range of the target business process in the first-level cache; the current processable state range is used to indicate the hierarchical state range that the target business process can currently process; obtain the state identifier and attribute information of the target message in the second-level cache; and determine whether the state identifier matches the current processable state range based on the different types of the attribute information. If yes, the target message is sent to the subscription queue as an ordered message, and the current processable state range is updated; otherwise, the target message is retained in the cache set.

7. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-5 is implemented.

8. A program product, characterized in that, When the program product is executed by the processor, it implements the method as described in any one of claims 1-5.

Images