Event-driven distributed transaction eventual consistency coordination method and system

Abstract

The application belongs to the technical field of computer program intercommunication, and discloses a distributed transaction eventual consistency coordination method and system based on event driving, which is applied to a microservice architecture. A first microservice node encapsulates a local event as a transaction event message carrying a global communication identifier, an event serial number and a subscription process identifier set, and sends the transaction event message to a message broker node through an event bus; the message broker node establishes a confirmation vector and a communication closed loop state machine, writes the transaction event message into an inter-process message mailbox of a second microservice node based on a subscription window, and generates a corresponding reverse compensation event message when the event serial number is discontinuous or a confirmation feedback conflict occurs, and updates the communication closed loop state in combination with a current broker epoch identifier. The scheme is used for realizing coordination of asynchronous event communication states among multiple microservice nodes.

Description

Technical Field

[0001] This invention relates to the field of computer program communication technology, and in particular to an event-driven distributed transaction eventual consistency coordination method and system. Background Technology

[0002] As software systems are gradually broken down into multiple independently deployed microservices, each microservice typically runs as an independent process. Different microservices have independent runtime environments and cannot directly share runtime states. When collaborative processing is required to complete continuous workflows, asynchronous communication between programs is usually achieved through event buses, message broker nodes, or publish-subscribe mechanisms. These communication methods generally involve an event publishing process generating event messages, which are then distributed to one or more event subscribing processes via the event bus or message broker node. The event subscribing processes then listen to, parse, and acknowledge the received event messages, thus forming an event-driven communication process in a distributed architecture.

[0003] For example, the invention patent with authorization announcement number CN110968586B discloses a distributed transaction processing method and apparatus. It uses an event bus as the communication medium between publishers and subscribers. The publisher publishes events to the event bus, which distributes the events to the corresponding subscribers and records the event status after the publisher and subscribers operate on the events. The event status is then sent back to the publisher. This type of solution can establish an asynchronous communication channel between publishers and subscribers through the event bus and track the event processing process using event status recording.

[0004] However, in scenarios where microservices run as independent processes, multiple second microservice nodes may simultaneously subscribe to transaction event messages published by the same first microservice node. The listening time, processing order, and acknowledgment return time of each subscribing process are not entirely consistent. Existing methods that record event states via an event bus can typically reflect whether an event has been distributed and whether the subscriber has returned a response, but they do not further differentiate the event reception order, event acknowledgment correspondence, and exception acknowledgment types on the subscribing process side. When a subscribing process receives event messages with discontinuous sequence numbers, existing solutions often struggle to directly determine the range of events requiring re-request, making the subsequent processing objects or scope unclear.

[0005] Meanwhile, during asynchronous communication between programs, the event subscription process may return multiple communication status confirmation messages for the same consumed event. If the event consumption content corresponding to these multiple communication status confirmation messages is inconsistent, existing event status recording methods typically struggle to distinguish between general duplicate confirmations and inconsistent confirmation returns, and also find it difficult to isolate confirmation locations with inconsistent confirmation returns. In this situation, if the message broker node continues to advance the event communication status based on such confirmation messages, it may lead to a mismatch between the confirmation return status and the actual event consumption status.

[0006] Furthermore, when a message broker node undergoes a runtime switch or the event communication state resumes, subsequent processing event messages that have been generated but not yet completed may continue to arrive at the second microservice node. Existing solutions based on event buses and response status records typically do not perform stage identification for subsequent processing event messages generated at different operational stages, making it difficult for the second microservice node to determine whether a delayed subsequent processing event message still belongs to the current event communication process.

[0007] Therefore, the main technical problem to be solved in the asynchronous communication process between programs in a microservice architecture is: how to identify situations such as discontinuous event sequence numbers, inconsistent acknowledgment returns, and unclear stages of subsequent processing event messages when multiple subscribing processes participate in event-driven communication, and how to ensure that the event communication state can form a closed update. Summary of the Invention

[0008] To overcome the aforementioned technical deficiencies, the present invention aims to provide an event-driven distributed transaction eventual consistency coordination method and system. This invention employs the configuration of inter-process message mailboxes for each second microservice node, combined with subscription windows, acknowledgment vectors, missing event compensation events, slot freeze compensation events, current agent epoch identifiers, and a communication closed-loop state machine, to identify, isolate, compensate for, and update the communication state for discontinuous event sequence numbers, inconsistent acknowledgment feedback, and unclear stages of subsequent processing event messages.

[0009] This invention discloses an event-driven distributed transaction eventual consistency coordination method, applied to inter-process event communication in a microservice architecture. The microservice architecture includes a first microservice node, a message broker node, multiple second microservice nodes, and an event bus. Each second microservice node runs as a subscribing process and is configured with an inter-process message mailbox. The inter-process message mailbox includes an ordered message area, an out-of-order temporary storage area, and an acknowledgment slot area. The acknowledgment slot area includes acknowledgment slots that match the identifier of the corresponding subscribing process. The method includes:

[0010] The first microservice node encapsulates local events into transactional event messages carrying a global communication identifier, event sequence number, and a set of subscription process identifiers, and sends them to the message broker node via the event bus;

[0011] The message broker node establishes an acknowledgment vector and a communication closed-loop state machine based on the set of subscription process identifiers. The acknowledgment vector includes vector bits corresponding to the acknowledgment slots and maintains a corresponding subscription window for each second microservice node. Based on the subscription window, the transaction event message is written to the corresponding sequential message area or out-of-order temporary storage area.

[0012] When the message broker node detects that there are event sequence numbers that have not been delivered consecutively in the subscription window, it extracts and generates a set of missing sequence numbers, generates a missing event compensation event, and requests the first microservice node to resend the transaction event message only for the set of missing sequence numbers.

[0013] The second microservice node consumes transaction event messages in the sequential message area and writes a communication status confirmation message carrying the consumed event sequence number and consumption fingerprint to the corresponding confirmation slot.

[0014] When a message broker node has communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot, it intercepts the update of the corresponding vector bit in the confirmation vector and generates a slot freeze compensation event.

[0015] The message broker node maintains the current broker epoch identifier, generates and distributes reverse compensation event messages carrying the current broker epoch identifier based on a pre-configured compensation type mapping table. The reverse compensation event messages include missing event compensation events and slot freeze compensation events, and update the communication closed loop state of the transaction event messages based on the communication closed loop state machine.

[0016] Preferably, the transaction event message further includes a publishing process identifier, a communication phase marker, an event payload summary, and an acknowledgment return topic; the first microservice node establishes a log index in its local event communication log corresponding to the global communication identifier and the event sequence number, and writes the transaction event message into the log record corresponding to the log index.

[0017] Preferably, the subscription window includes a consumption sequence number, a window start sequence number, and a window end sequence number; the message broker node maintains a corresponding subscription window for each second microservice node based on the global communication identifier, the subscription process identifier set, and the event sequence number.

[0018] Preferably, when the event sequence number is equal to the pending consumption sequence number, the message broker node writes the transaction event message into the sequential message area; when the event sequence number is greater than the pending consumption sequence number but does not exceed the window end sequence number, the transaction event message is written into the out-of-order temporary storage area, and the event sequence numbers between the pending consumption sequence number and the event sequence number that have not been written into the corresponding inter-process message mailbox are written into the missing sequence number set.

[0019] Preferably, when the missing sequence number set is empty, the message broker node transfers the transaction event messages in the out-of-order temporary storage area to the ordered message area in ascending order of event sequence numbers; when the missing sequence number set is not empty, the acknowledgment slot corresponding to the second microservice node with event sequence numbers that have not been delivered consecutively is marked as out-of-order missing.

[0020] Preferably, the missing event compensation event includes a global communication identifier, the subscription process identifier corresponding to the second microservice node with non-continuously delivered event sequence numbers, a set of missing sequence numbers, and a missing event compensation feedback topic; the first microservice node reads the transaction event message corresponding to the set of missing sequence numbers from the local event communication log according to the missing event compensation event, and resends the read transaction event message via the event bus.

[0021] Preferably, the communication status confirmation message further includes a global communication identifier, a subscription process identifier, a parsing status flag, and a processing status flag; the parsing status flag includes a parsing success status and a parsing exception status, and the processing status flag includes a processing completion flag and a processing exception flag; before generating the communication status confirmation message, the second microservice node compares the event sequence number of the transaction event message to be consumed with the consumption sequence number in the subscription window, and generates a consumption fingerprint when the two match.

[0022] Preferably, when a message broker node has communication status confirmation messages with the same consumed event sequence number and the same consumption fingerprint in the same confirmation slot, the corresponding confirmation slot is marked as a duplicate confirmation state; when there are communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot, the corresponding confirmation slot is marked as a confirmation conflict state.

[0023] Preferably, when the acknowledgment slot is marked as an acknowledgment conflict state, the message broker node sets the vector bit corresponding to the acknowledgment slot in the acknowledgment vector to a frozen state, so as to intercept the update of the corresponding vector bit and stop the state transition of the communication closed-loop state machine triggered by the acknowledgment message based on the communication status in the acknowledgment slot.

[0024] Preferably, the slot freeze compensation event includes a global communication identifier, the subscription process identifier of the second microservice node corresponding to the confirmed conflict state, the frozen slot identifier, the conflict confirmation summary, and the freeze feedback topic; the second microservice node corresponding to the slot freeze compensation event stops reading the transaction event message corresponding to the frozen slot identifier from the sequential message area according to the slot freeze compensation event, and returns a slot freeze confirmation message to the freeze feedback topic.

[0025] Preferably, the compensation type mapping table includes a confirmation status field, a compensation type field, a compensation target field, and a compensation trigger field; the confirmation status field includes unconfirmed status, out-of-order missing status, parsing exception status, duplicate confirmation status, and confirmation conflict status; the message broker node maps the unconfirmed status to a redelivery compensation event, the out-of-order missing status to a missing event compensation event, the parsing exception status to a format reconstruction compensation event, the duplicate confirmation status to an idempotent masking compensation event, and the confirmation conflict status to a slot freeze compensation event.

[0026] Preferably, the idempotent masking compensation event includes a global communication identifier, the subscription process identifier of the second microservice node that triggered the idempotent masking compensation event, the consumed event sequence number, and the consumption fingerprint; the second microservice node that receives the idempotent masking compensation event establishes a masking slot in the confirmation slot area according to the idempotent masking compensation event, writes the consumption fingerprint into the masking slot, and prevents transaction event messages with the same consumption fingerprint from entering the sequential message area.

[0027] Preferably, the communication closed-loop state machine includes a waiting-to-route state, a mailbox-entered state, a sequential waiting state, a partial confirmation state, a compensation distribution state, a compensation confirmation state, and a closed-loop completion state; the message broker node will migrate the communication closed-loop state machine to the closed-loop completion state only when there are no frozen vector bits in the confirmation vector and the processing status markers in the confirmation slots corresponding to all vector bits are processing completion markers.

[0028] Preferably, the message broker node updates the current broker epoch identifier when a primary / backup switch occurs; the second microservice node only processes reverse compensation event messages that are consistent with the current broker epoch identifier, establishes a failure event slot in the confirmation slot area, and writes the reverse compensation event messages that are not corresponding to the current broker epoch identifier into the failure event slot.

[0029] In view of this, the present invention also provides an event-driven distributed transaction eventual consistency coordination system, including a first microservice node, a message broker node, multiple second microservice nodes and an event bus;

[0030] Each second microservice node runs as a subscription process and is configured with an inter-process message mailbox. The inter-process message mailbox includes a sequential message area, an out-of-order temporary storage area, and an acknowledgment slot area. The acknowledgment slot area includes acknowledgment slots that match the identifier of the corresponding subscription process.

[0031] The first microservice node includes an event encapsulation module, which encapsulates local events into transactional event messages carrying a global communication identifier, event sequence number, and a set of subscription process identifiers, and sends them to the message broker node via the event bus.

[0032] The message broker node includes a subscription window management module, an acknowledgment vector management module, a missing compensation module, a slot freezing module, a compensation type mapping module, a broker epoch maintenance module, and a communication closed-loop state machine module;

[0033] The subscription window management module is used to maintain the corresponding subscription window for each second microservice node, and write transaction event messages into the corresponding ordered message area or out-of-order temporary storage area based on the subscription window;

[0034] The confirmation vector management module is used to establish confirmation vectors based on the subscription process identifier set. The confirmation vector includes vector bits corresponding to the confirmation slots.

[0035] The missing event compensation module is used to extract and generate a set of missing event numbers when it detects that there are event numbers that have not been delivered consecutively in the subscription window, generate a missing event compensation event, and request the first microservice node to resend the transaction event message only for the set of missing event numbers.

[0036] The second microservice node is used to consume transaction event messages in the sequential message area and write communication status confirmation messages carrying the consumed event sequence number and consumption fingerprint to the corresponding confirmation slot;

[0037] The slot freeze module is used to intercept the update of the corresponding vector bit in the confirmation vector and generate a slot freeze compensation event when there are communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot.

[0038] The proxy epoch maintenance module is used to maintain the current proxy epoch identifier;

[0039] The compensation type mapping module is configured with a compensation type mapping table and is used to generate and distribute reverse compensation event messages carrying the current agent epoch identifier based on the compensation type mapping table. The reverse compensation event messages include missing event compensation events and slot freeze compensation events.

[0040] The communication closed-loop state machine module is used to establish the communication closed-loop state machine and update the communication closed-loop state of transaction event messages based on the communication closed-loop state machine.

[0041] Compared with existing technologies, the above technical solution has the following advantages:

[0042] 1. This invention configures an inter-process message mailbox, including a sequential message area, an out-of-order temporary storage area, and an acknowledgment slot area, for the second microservice node during inter-process event communication in a microservice architecture. The message broker node, in conjunction with the subscription window, controls the writing of transaction event messages. This enables the differentiation between sequential and out-of-order messages when multiple subscribing processes receive transaction event messages in parallel, ensuring a clear correspondence between the receiving order, temporary storage location, and acknowledgment location of event messages. This improves the accuracy of asynchronous event communication state coordination between microservice nodes.

[0043] 2. This invention identifies event sequence numbers that are not delivered consecutively in the subscription window through message broker nodes, extracts and generates a set of missing sequence numbers, and then generates missing event compensation events based on the set of missing sequence numbers. This enables the first microservice node to resend only the transaction event messages corresponding to the set of missing sequence numbers, avoiding repeated compensation for transaction event messages that have already been delivered or temporarily stored, reducing the number of invalid message resends, and improving the compensation processing efficiency in the event-driven communication process.

[0044] 3. This invention receives communication status confirmation messages carrying the sequence number and consumption fingerprint of consumed events in the confirmation slot area. When communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints appear in the same confirmation slot, the update of the corresponding vector bit in the confirmation vector is intercepted and a slot freeze compensation event is generated. This can distinguish between duplicate confirmations and confirmation conflicts, and prevent message broker nodes from continuing to advance the communication closed loop state based on abnormal confirmation messages, thereby improving the consistency between the communication status confirmation process and the actual event consumption process. Attached Figure Description

[0046] Figure 1 This is a diagram illustrating the underlying logical architecture of inter-service event communication provided in an embodiment of the present invention.

[0047] Figure 2 A flowchart illustrating the event-driven distributed transaction eventual consistency coordination method provided in this embodiment of the invention;

[0048] Figure 3 This is a flowchart illustrating the out-of-order interception and confirmation conflict handling process provided in an embodiment of the present invention.

[0049] Figure 4 A timing diagram illustrating the cross-process asynchronous message interaction and compensation processing procedure provided in an embodiment of the present invention;

[0050] Figure 5 This is a schematic diagram of the state transition of a communication closed-loop state machine provided in an embodiment of the present invention;

[0051] Figure 6A schematic diagram of the structure of an event-driven distributed transaction eventual consistency coordination system provided in an embodiment of the present invention;

[0052] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0054] The present embodiment will be further described below with reference to the accompanying drawings and specific examples. It should be understood that the following examples are only for illustrating possible implementations and are not intended to limit the scope of protection. Where there is no conflict, the technical features in the following examples can be combined with each other.

[0055] This embodiment provides an event-driven distributed transaction eventual consistency coordination method, suitable for inter-program event communication scenarios in microservice architectures. See also... Figure 1 The microservice architecture comprises a first microservice node, a message broker node, multiple second microservice nodes, and an event bus. Each second microservice node runs as a subscription process and is configured with an inter-process message mailbox. The inter-process message mailbox includes a sequential message area, an out-of-order buffer area, and an acknowledgment slot area. The acknowledgment slot area includes acknowledgment slots that match the identifier of the corresponding subscription process. The first microservice node runs as an event publishing process, and the second microservice nodes run as event subscription processes. The event bus is used to carry out asynchronous message transmission between the first microservice node and the message broker node. The message broker node is used to perform subscription window maintenance, acknowledgment vector updates, missing message compensation, slot freeze compensation, broker epoch maintenance, and communication loop state updates.

[0056] See Figure 2 After the first microservice node responds to a local event, it encapsulates the local event into a transactional event message and sends it to the message broker node via the event bus. The transactional event message carries at least a global communication identifier, an event sequence number, and a set of subscribing process identifiers. To facilitate serialization, transmission, and parsing by computer devices, the transactional event message can be encapsulated in JSON format, with an example of its field-level structure as follows:

[0057] {

[0058] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0059] "Event_Seq": 105,

[0060] "Pub_PID": "First_Service_Process_01",

[0061] "Sub_PIDs": ["Second_Service_Process_A", "Second_Service_Process_B"],

[0062] "Stage_Flag": "Forward_Event",

[0063] "Epoch_ID": "Epoch_NodeA_v2",

[0064] "Payload_Digest": "0x8A7B9C21EF65",

[0065] "Ack_Topic": "ack.topic.Tx-2025-0611-UUID890"

[0066] }

[0067] The structure includes the following fields: "Global_Msg_ID" (global communication identifier), "Event_Seq" (event sequence number), "Pub_PID" (publishing process identifier), "Sub_PIDs" (subscribing process identifier set), "Stage_Flag" (communication stage flag), "Epoch_ID" (current agent epoch identifier), "Payload_Digest" (event payload digest), and "Ack_Topic" (acknowledgment topic). The event payload digest can be obtained by hashing the local event payload content on the first microservice node and is used to assist in determining whether the consumed event content is consistent during the communication status confirmation process. Upon receiving a transaction event message carrying the "Epoch_ID" field, the second microservice node writes the corresponding current agent epoch identifier into its local epoch identifier cache and uses it as a comparison benchmark when processing subsequent reverse compensation event messages.

[0068] In this embodiment, the communication stage marker is used to identify the communication stage of the transaction event message. When the communication stage marker is "Forward_Event", the message broker node treats the transaction event message as a forward event message for subscription window matching and mailbox writing; when the communication stage marker is a compensation-related stage marker, the message broker node distributes the reverse compensation event message according to the compensation type mapping table. Through this communication stage marker, the message broker node can distinguish between forward delivery messages and compensation messages.

[0069] The first microservice node establishes a log index in its local event communication log corresponding to the global communication identifier and event sequence number, and writes the transaction event message to the log record corresponding to this log index. The local event communication log can be stored using a key-value structure, where the key is formed by concatenating the global communication identifier and event sequence number, and the value includes the original transaction event message, sending time, retransmission count, and communication stage marker. For example, when the global communication identifier is "Tx-2025-0611-UUID890" and the event sequence number is 105, the corresponding log index is "Tx-2025-0611-UUID890:105". The local event communication log can be stored in the first microservice node's local memory cache, append-only log file, or lightweight key-value store area.

[0070] After receiving a transaction event message, the message broker node establishes an acknowledgment vector and a communication closed-loop state machine based on the set of subscriber process identifiers. The acknowledgment vector includes vector bits corresponding to acknowledgment slots. In this embodiment, the acknowledgment vector is instantiated as a two-bit bitmap in the memory of the message broker node, and the correspondence between vector bits and acknowledgment slots is established according to the order of subscriber process identifiers in the set of subscriber process identifiers. Every two bits correspond to the current state of an acknowledgment slot. The state encoding of the acknowledgment vector is shown in Table 1.

[0071] Table 1 Confirmation Vector State Coding Table

[0072] 0 Unconfirmed status The corresponding confirmation slot has not yet been written with a valid communication status confirmation message. 1 Processing completed The corresponding confirmation slot's processing status marker is now marked as "processing complete". 10 Out-of-order missing state There are event numbers in the corresponding subscription window that have not been delivered consecutively. 11 Frozen state There are inconsistent communication status confirmation messages in the corresponding confirmation slots.

[0073] For example, when the subscription process identifier set includes "Second_Service_Process_A" and "Second_Service_Process_B", the message broker node establishes an acknowledgment vector in memory, consisting of two vector bits. The first vector bit corresponds to the acknowledgment slot of the second microservice node A, and the second vector bit corresponds to the acknowledgment slot of the second microservice node B. Initially, both vector bits are "00".

[0074] The message broker node also maintains a corresponding subscription window for each second microservice node. The subscription window includes a consumption sequence number, a window start sequence number, and a window end sequence number. Taking second microservice node A as an example, the data structure of the subscription window can be represented as follows:

[0075] {

[0076] "Sub_PID": "Second_Service_Process_A",

[0077] "Window_Start_Seq": 103,

[0078] "Expected_Consume_Seq": 105,

[0079] "Window_End_Seq": 110

[0080] }

[0081] The fields “Sub_PID” correspond to the subscription process identifier, “Window_Start_Seq” corresponds to the window start sequence number, “Expected_Consume_Seq” corresponds to the pending consumption sequence number, and “Window_End_Seq” corresponds to the window end sequence number. The message broker node determines whether the transaction event message should enter the ordered message area or the out-of-order temporary storage area based on this subscription window.

[0082] See Figure 3 When a message broker node receives a transaction event message with event sequence number 105, and the corresponding second microservice node also has a consumption sequence number of 105, the message broker node writes the transaction event message into the sequential message area of ​​the corresponding inter-process message mailbox. When a message broker node receives a transaction event message with event sequence number 108, and the corresponding second microservice node has a consumption sequence number of 105, and the event sequence number 108 does not exceed the window end sequence number 110, the message broker node writes the transaction event message with event sequence number 108 into the out-of-order temporary storage area, and extracts the event sequence numbers between the consumption sequence number and the preceding sequence number that have not been written to the corresponding inter-process message mailbox as a missing sequence number set. At this time, the missing sequence number set can be represented as:

[0083] {

[0084] "Missing_Seq_Set": [105, 106, 107]

[0085] }

[0086] When a message broker node detects that there are event sequence numbers that have not been delivered consecutively in the subscription window, it extracts and generates a set of missing sequence numbers, generates a missing event compensation event, and requests the first microservice node to resend the transaction event message only for the set of missing sequence numbers. The missing event compensation event includes a global communication identifier, the subscription process identifier corresponding to the second microservice node with the missing event sequence numbers, the set of missing sequence numbers, and the missing event compensation feedback topic. For example, the data structure of the missing event compensation event is as follows:

[0087] {

[0088] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0089] "Target_Sub_PID": "Second_Service_Process_A",

[0090] "Missing_Seq_Set": [105, 106, 107],

[0091] "Miss_Comp_Topic": "comp.missing.Tx-2025-0611-UUID890"

[0092] }

[0093] After receiving the missing event compensation event, the first microservice node reads the corresponding transaction event message from the local event communication log according to the missing sequence number set, and retransmits the read transaction event message via the event bus. Since the retransmission scope is limited by the missing sequence number set, the first microservice node does not retransmit transaction event messages that have already been written to the sequential message area or the out-of-order temporary storage area.

[0094] When the set of missing sequence numbers is empty, the message broker node transfers the transaction event messages in the out-of-order temporary storage area to the ordered message area in ascending order of event sequence numbers. When the set of missing sequence numbers is not empty, the message broker node marks the acknowledgment slot corresponding to the second microservice node with event sequence numbers that have not been delivered consecutively as out-of-order and missing, and updates the corresponding vector bit in the acknowledgment vector to "10".

[0095] The second microservice node consumes only transaction event messages from the sequential message area. Before consumption, the second microservice node compares the event sequence number of the transaction event message to be consumed with the event sequence number to be consumed in the subscription window, and generates a consumption fingerprint if they match. In this embodiment, the consumption fingerprint is calculated based on the global communication identifier, the consumed event sequence number, the subscription process identifier, the event payload digest, and the local consumption timestamp. The calculation formula for the consumption fingerprint is as follows:

[0096]

[0097] in, Indicates the consumer's fingerprint; This indicates that the first 16 hexadecimal characters of the hash result should be extracted. This indicates SHA-256 hash calculation; This represents the global communication identifier, derived from the "Global_Msg_ID" field in the transaction event message; This indicates the sequence number of the consumed event, which originates from the transaction event message actually consumed by the second microservice node; This indicates the subscription process identifier, which originates from the process identifier of the second microservice node; This represents the event payload digest, derived from the "Payload_Digest" field in the transaction event message; This represents the local consumption timestamp, derived from the local clock of the second microservice node when it generates the communication status confirmation message; the symbol " " indicates string concatenation.

[0098] For example, if the global communication identifier is “Tx-2025-0611-UUID890”, the consumed event sequence number is 105, the subscription process identifier is “Second_Service_Process_A”, the event payload digest is “0x8A7B9C21EF65”, and the local consumption timestamp is “2025-06-11T10:30:15.102Z”, then the second microservice node A can obtain the consumption fingerprint “6F91AC20D882A3E1”.

[0099] After consuming transaction event messages in the sequential message area, the second microservice node writes a communication status confirmation message carrying the consumed event sequence number and consumption fingerprint to the corresponding confirmation slot. The communication status confirmation message also includes a global communication identifier, a subscription process identifier, a resolution status flag, and a processing status flag. The resolution status flag includes resolution successful and resolution error states, and the processing status flag includes a processing completed flag and a processing error flag.

[0100] When generating a communication status confirmation message, the second microservice node first performs deserialization verification on the transaction event message and recalculates the local payload digest based on the deserialized event payload. If the transaction event message cannot be deserialized into JSON, or if the recalculated local payload digest does not match the "Payload_Digest" field in the transaction event message, the second microservice node sets the parsing status flag to a parsing error state. If the transaction event message can be deserialized into JSON and the recalculated local payload digest matches the "Payload_Digest" field, the second microservice node sets the parsing status flag to a parsing success state. Therefore, the parsing error state has clear computer-defined judgment conditions and can trigger a format reconstruction compensation event in the compensation type mapping table.

[0101] The following is an example of the data structure for a communication status confirmation message:

[0102] {

[0103] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0104] "Sub_PID": "Second_Service_Process_A",

[0105] "Consumed_Seq": 105,

[0106] "Consume_Fingerprint": "6F91AC20D882A3E1",

[0107] "Parse_State": "Parse_OK",

[0108] "Process_State": "Process_Done"

[0109] }

[0110] The message broker node reads the communication status acknowledgment messages in the acknowledgment slot area and determines whether there are any communication status acknowledgment messages with the same consumed event sequence number and consumption fingerprint in the same acknowledgment slot, and whether there are any communication status acknowledgment messages with the same consumed event sequence number but different consumption fingerprints. When there are communication status acknowledgment messages with the same consumed event sequence number and consumption fingerprint in the same acknowledgment slot, the message broker node marks the corresponding acknowledgment slot as a duplicate acknowledgment. When there are communication status acknowledgment messages with the same consumed event sequence number but different consumption fingerprints in the same acknowledgment slot, the message broker node marks the corresponding acknowledgment slot as an acknowledgment conflict.

[0111] In a further implementation, to improve the stability of acknowledgment slot anomaly type identification, the message broker node can also generate an acknowledgment slot crack signature for each acknowledgment slot in the acknowledgment slot area. The acknowledgment slot crack signature is used to characterize the inconsistencies between the event sequence number, consumption fingerprint, vector bit state, and broker epoch identifier within the same acknowledgment slot. The calculation formula for the acknowledgment slot crack signature is as follows:

[0112]

[0113] in, This indicates the signature confirming the slot crack; GID represents the global communication identifier; SlotID represents the confirmation slot identifier. This indicates the subscription sequence number in the subscription window; This indicates the sequence number of the consumed event in the communication status confirmation message; The 'VB' represents the consumption fingerprint; VB represents the vector bit state corresponding to the acknowledgment slot in the acknowledgment vector; EpochID represents the current broker epoch identifier maintained by the message broker node; the symbol "||" represents string concatenation.

[0114] After the message broker node generates the confirmation slot crack signature, it writes the confirmation slot crack signature into the crack signature field of the confirmation slot area and performs secondary verification according to the crack type identification rules shown in Table 2.

[0115] Table 2. Rules for Identifying Crack Types in Confirmed Slots

[0116] Disorder cracks The consumed event sequence number is less than the pending event sequence number in the subscription window, and the corresponding vector bit of the confirmation vector is not in a frozen state. The corresponding confirmed slot will remain in a sequential waiting state, without triggering the closed-loop completion state. Repeated cracks The consumed event sequence number is the same, the consumption fingerprint is the same, and the confirmed slot crack signature is the same. Mark the corresponding confirmation slot as a duplicate confirmation status. Conflict cracks The consumed event numbers are the same but the consumption fingerprints are different, or the signatures for the confirmed slot cracks are different. Mark the corresponding confirmation slot as a confirmation conflict state. Epoch Crack The proxy epoch identifier is inconsistent with the current proxy epoch identifier in the local epoch identifier cache. Write the relevant message to the failure event slot.

[0117] For example, if the pending consumption sequence number in the subscription window corresponding to a certain acknowledgment slot is 105, the consumed event sequence number in the communication status acknowledgment message is also 105, the first consumption fingerprint written is "6F91AC20D882A3E1", and the second consumption fingerprint written is "7A02BD55E91C9F31", then even if the consumed event sequence numbers in the two communication status acknowledgment messages are the same, the acknowledgment slot crack signature generated by the message broker node will be different due to the different consumption fingerprints. The message broker node will identify this acknowledgment slot as a conflict crack and mark the corresponding acknowledgment slot as a acknowledgment conflict state. Through the acknowledgment slot crack signature, the message broker node can distinguish between duplicate acknowledgments, acknowledgment conflicts, out-of-order remnants, and epoch inconsistencies at the acknowledgment slot level, avoiding anomaly judgments based solely on a single status field.

[0118] When a confirmation slot is marked as being in a conflict state, the message broker node sets the vector bit corresponding to that confirmation slot in the confirmation vector to a frozen state. This intercepts updates to the corresponding vector bit and stops the state transition of the communication closed-loop state machine triggered by the confirmation message based on the communication status in that confirmation slot. Correspondingly, the message broker node generates a slot freeze compensation event. The slot freeze compensation event includes a global communication identifier, the subscription process identifier of the second microservice node corresponding to the conflict state, the frozen slot identifier, the conflict confirmation summary, and the frozen feedback topic. For example, the data structure of the slot freeze compensation event is as follows:

[0119] {

[0120] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0121] "Target_Sub_PID": "Second_Service_Process_B",

[0122] "Frozen_Slot_ID": "Slot_B_105",

[0123] "Conflict_Ack_Digest": "ACK-Conflict-0x3321AE",

[0124] "Freeze_Ack_Topic": "freeze.ack.Tx-2025-0611-UUID890"

[0125] }

[0126] The second microservice node corresponding to the slot freeze compensation event stops reading the transaction event message corresponding to the frozen slot identifier from the sequential message area and returns a slot freeze confirmation message to the freeze feedback topic. After the slot freeze confirmation message arrives at the message broker node, the message broker node maintains the frozen state of the corresponding vector bit until a valid conflict resolution confirmation message or a newly generated valid communication status confirmation message is written to the slot area.

[0127] The message broker node maintains the current broker epoch identifier. This identifier identifies the current operational phase of the message broker node. For example, the current broker epoch identifier can be represented as "Epoch_NodeA_v2". When a primary / backup switch occurs, the message broker node updates its current broker epoch identifier, for example, from "Epoch_NodeA_v2" to "Epoch_NodeB_v1". The message broker node generates and distributes a reverse compensation event message carrying the current broker epoch identifier based on a pre-configured compensation type mapping table. Upon receiving the reverse compensation event message, the second microservice node compares the broker epoch identifier carried in the message with the current broker epoch identifier stored in its local epoch identifier cache. If they match, the second microservice node processes the reverse compensation event message; otherwise, it creates a failure event slot in its acknowledgment slot area and writes the reverse compensation event message to the failure event slot.

[0128] After a primary / backup switch occurs at the message broker node, the message broker node can send a broker epoch update message to each second microservice node via the event bus. This message carries the updated current broker epoch identifier. Upon receiving the message, each second microservice node updates its local epoch identifier cache with the current broker epoch identifier carried in the update message. This provides the second microservice node with the necessary comparison benchmark for processing reverse compensation event messages.

[0129] In a further implementation, to prevent the reverse compensation event messages generated before the primary / standby switchover of the message broker node from being mishandled by the second microservice node after the switchover, the message broker node can also generate a broker epoch double-watermark echo lock for each reverse compensation event message. The broker epoch double-watermark echo lock includes a broker epoch sending watermark, a second microservice node local watermark, and a compensation echo watermark. The broker epoch sending watermark is written to the reverse compensation event message by the message broker node when generating it; the second microservice node local watermark is stored in the second microservice node's local epoch identifier cache; the compensation echo watermark is written to the frozen return topic or missing compensation return topic by the second microservice node when returning a compensation confirmation message.

[0130] The formula for calculating the watermark sent by the proxy era is as follows:

[0131]

[0132] in, The following parameters represent the watermark sent by the agent epoch: EpochID (current agent epoch identifier), GID (global communication identifier), ES (event sequence number), CompType (compensation type field), SlotID (acknowledgment slot identifier), and CompSeq (incrementing compensation sequence number generated under the same current agent epoch identifier). The calculation formula for the local watermark on the second microservice node is as follows:

[0133]

[0134] in, This represents the local watermark of the second microservice node; LocalEpochID represents the current proxy epoch identifier stored in the local epoch identifier cache. The second microservice node only processes the reverse compensation event message and generates a compensation echo watermark when the watermark sent by the proxy epoch matches the local watermark of the second microservice node. The calculation formula for the compensation echo watermark is as follows:

[0135]

[0136] in, This indicates the compensation watermark; SPID indicates the subscription process identifier of the second microservice node; AckTime indicates the timestamp of the second microservice node generating the compensation confirmation message.

[0137] When a message broker node receives a compensation confirmation message, it performs a consistency check based on the watermark stored in its own agent epoch and the compensation echo watermark in the compensation confirmation message. If the compensation echo watermark can be verified by the watermark sent by the current agent epoch and the local watermark corresponding to the second microservice node, the message broker node allows the communication closed-loop state machine to continue migrating. If the compensation echo watermark fails the verification, the message broker node does not unfreeze the corresponding confirmation slot and writes the compensation confirmation message to the failure event slot. Through the agent epoch dual-watermark echo lock, the reverse compensation event message not only carries the current agent epoch identifier but also echoes its local epoch comparison result after processing by the second microservice node, thereby blocking the impact of the old agent epoch compensation event on the current communication closed-loop state at the inter-program communication level.

[0138] In this embodiment, the proxy epoch double watermark echo lock can be used as an extended field of the reverse compensation event message, and its data structure is shown in the following example:

[0139] {

[0140] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0141] "Event_Seq": 105,

[0142] "Epoch_ID": "Epoch_NodeA_v2",

[0143] "Comp_Type": "Slot_Freeze_Compensation",

[0144] "Frozen_Slot_ID": "Slot_B_105",

[0145] "Comp_Seq": 3,

[0146] "Epoch_Send_Watermark": "C1D6A9207B3E4412",

[0147] "Echo_Topic": "echo.watermark.Tx-2025-0611-UUID890"

[0148] }

[0149] The compensation confirmation message returned by the second microservice node after processing the reverse compensation event message can be represented as follows:

[0150] {

[0151] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0152] "Sub_PID": "Second_Service_Process_B",

[0153] "Local_Epoch_ID": "Epoch_NodeA_v2",

[0154] "Comp_Seq": 3,

[0155] "Epoch_Echo_Watermark": "A9F31C08E226DD40",

[0156] "Comp_Ack_State": "Echo_OK"

[0157] }

[0158] In this embodiment, the pre-configured compensation type mapping table is shown in Table 3.

[0159] Table 3 Compensation Type Mapping Relationship Table

[0160] Unconfirmed status Confirmation message not written to slot. Redelivery Compensation Event Inter-process message mailbox corresponding to the second microservice node Re-push into the queue to be routed Out-of-order missing state There are event numbers in the subscription window that have not been delivered consecutively. Missing event compensation event Local event communication logs of the first microservice node Read and resend based on the set of missing sequence numbers. Analyzing abnormal states JSON deserialization failed, or the local payload digest is inconsistent with the "Payload_Digest" field. Format Reconstruction Compensation Event First microservice node or message broker node Re-encapsulate the corresponding transaction event message Repeated confirmation status There are communication status confirmation messages with the same sequence number and the same consumer fingerprint in the same confirmation slot. Idempotent shielding compensation event Confirmation slot area of ​​the second microservice node Create a shielded slot and write the consumer fingerprint. Confirm conflict status Communication status confirmation messages with the same sequence number but different consumer fingerprints exist in the same confirmation slot. Slot Freeze Compensation Event Confirmation slot for the second microservice node Freeze the corresponding confirmed slot and return a slot freeze confirmation message.

[0161] An idempotent masking compensation event includes a global communication identifier, the subscription process identifier of the second microservice node that triggered the idempotent masking compensation event, the consumed event sequence number, and the consumption fingerprint. The second microservice node receiving the idempotent masking compensation event creates a masking slot in the acknowledgment slot area based on the idempotent masking compensation event, writes the consumption fingerprint into the masking slot, and prevents transaction event messages with the same consumption fingerprint from entering the sequential message area.

[0162] See Figure 5 The communication closed-loop state machine includes the following states: pending routing, mail received, sequential waiting, partial confirmation, compensation distribution, compensation confirmation, and closed-loop completion. The transition rules of the communication closed-loop state machine are shown in Table 4.

[0163] Table 4 Communication Closed-Loop State Machine Flow Table

[0164] pending routing status Transaction event messages enter the message broker node Inbox status Inbox status Transaction event messages are written to the corresponding inter-process message mailbox. Sequential waiting state Sequential waiting state The second microservice node consumes transaction event messages in the sequential message area. Partially confirmed status Partially confirmed status There are out-of-order missing states, parsing error states, duplicate confirmation states, or confirmation conflict states. Compensation Distribution Status Compensation Distribution Status Reverse compensation event message distribution completed Compensation Confirmation Status Compensation Confirmation Status The compensation confirmation message is written to the corresponding confirmation slot. Partially confirmed status or closed-loop completion status Partially confirmed status The confirmation vector contains no frozen vector bits, and the processing status markers in the confirmation slots corresponding to all vector bits are all processing completed markers. Closed loop completion status Compensation Confirmation Status Compensation watermark verification failed Compensation distribution status or partial confirmation status Compensation Confirmation Status The compensated watermark verification passed, and it was confirmed that there are no frozen vector bits in the vector. Closed loop completion status

[0165] The message broker node transitions the communication closed-loop state machine to the closed-loop completion state only when there are no frozen vector bits in the acknowledgment vector and all processing status markers in the acknowledgment slots corresponding to the vector bits are processing completion markers. If there are frozen vector bits in the acknowledgment vector, the communication closed-loop state machine will not transition to the closed-loop completion state even if other subscribing processes have returned processing completion markers. In the implementation using the proxy epoch double watermark echo lock, the message broker node also needs to complete the compensation echo watermark verification in the compensation acknowledgment state. Only when the compensation echo watermark verification passes and the acknowledgment vector meets the closed-loop completion conditions will the communication closed-loop state machine transition to the closed-loop completion state.

[0166] To illustrate the specific execution process of this embodiment, see [link to relevant documentation]. Figure 4The first microservice node sends a transaction event message with a global communication identifier of "Tx-2025-0611-UUID890" and an event sequence number of 105 to the message broker node. The message broker node determines that both the second microservice node A and the second microservice node B are subscribing processes based on the set of subscribing process identifiers and maintains their respective subscription windows. When the pending consumption sequence number of the second microservice node A is 105, the message broker node writes the transaction event message into the sequential message area of ​​the second microservice node A; when the pending consumption sequence number of the second microservice node B is 103 and the window end sequence number is 110, the message broker node writes the transaction event message into the out-of-order temporary storage area of ​​the second microservice node B and extracts the missing sequence number set [103, 104]. The message broker node generates a missing event compensation event, requesting the first microservice node to resend only the transaction event messages with event sequence numbers 103 and 104. The first microservice node reads the corresponding log record from its local event communication log and resends it via the event bus.

[0167] After the second microservice node A consumes the transaction event message with event sequence number 105, it writes a communication status confirmation message to the corresponding confirmation slot. The consumption fingerprint in the communication status confirmation message is "6F91AC20D882A3E1". If the second microservice node A returns a communication status confirmation message with the same consumed event sequence number and the same consumption fingerprint, the message broker node marks the corresponding confirmation slot as a duplicate confirmation and generates an idempotent masking compensation event based on the compensation type mapping table. If the second microservice node A returns a communication status confirmation message with the same consumed event sequence number but a different consumption fingerprint, the message broker node marks the corresponding confirmation slot as a confirmation conflict state, sets the corresponding vector bit to a frozen state, and generates a slot freeze compensation event. In a further implementation using confirmation slot crack signatures, the message broker node also generates a confirmation slot crack signature and identifies the corresponding confirmation slot as a conflict crack based on the confirmation slot crack signature to confirm that the confirmation slot should enter the freeze process.

[0168] To verify the technical effectiveness of this embodiment, the event bus state recording scheme described in the background art was used as a control scheme, and asynchronous communication tests between programs were conducted in the same simulated environment. The simulated environment included a first microservice node, a message broker node, two second microservice nodes, and an event bus. 10,000 transaction event messages were continuously sent, with randomized scenarios including 1.5% discontinuous event sequence numbers, 1.0% duplicate acknowledgments, 0.3% inconsistent acknowledgment feedback, and one message broker node master-slave switchover scenario. The statistical criteria were as follows: the number of times a specific missing event sequence number could be located represented the number of times the missing sequence number set could be extracted from the abnormal event; the average number of compensated retransmission events represented the number of transaction event messages retransmitted each time missing event compensation was triggered; and the number of times the system was incorrectly pushed into the closed-loop completion state represented the number of times the system entered the closed-loop completion state even when there was a frozen state vector bit or unprocessed abnormal acknowledgments. The test results are shown in Table 5.

[0169] Table 5. Comparison Test Results with Existing Event Status Recording Schemes

[0170] Number of scenarios with non-contiguous event sequence numbers 150 times 150 times The number of times a specific event sequence number can be located. 43 times 150 times Average number of recurring compensation events 7.8 items / time 2.1 items / time Repeated confirmation number of times 100 times 100 times Confirmation of inconsistent identification count 9 times 30 times Number of times the loop was incorrectly pushed to the closed-loop completion state 12 times 0 times Number of times compensation event messages not in the current running phase are processed 6 times 0 times Average closure time of a single transaction event message 36.4 milliseconds 28.7 milliseconds Number of misjudgments of slot anomaly type 11 times 0 times Number of mishandled old era compensation events after primary / standby switchover 6 times 0 times

[0171] As shown in Table 5, under the same test conditions, this embodiment can distinguish and process event messages with discontinuous event numbers, inconsistent acknowledgment feedback, and compensation events outside the current running stage, and enables the communication closed-loop state machine to transition to the closed-loop completion state when the acknowledgment vector meets the preset state conditions. The above test results correspond to the coordination relationships between the inter-process message mailbox, subscription window, missing event compensation event, acknowledgment slot area, acknowledgment vector, slot freeze compensation event, current agent epoch identifier, and communication closed-loop state machine. In the further implementation using acknowledgment slot crack signature and agent epoch double watermark echo lock, different anomaly patterns can be identified at the acknowledgment slot level, and watermark verification can be performed on the reverse compensation event messages generated by the old agent epoch, thereby reducing the probability of misjudgment of slot anomaly types and misprocessing of old epoch compensation events.

[0172] This embodiment provides an event-driven distributed transaction eventual consistency coordination system. See also... Figure 6 The system comprises a first microservice node, a message broker node, multiple second microservice nodes, and an event bus. Each second microservice node runs as a subscribing process and is configured with an inter-process message mailbox. The inter-process message mailbox includes a sequential message area, an out-of-order buffer area, and an acknowledgment slot area. The acknowledgment slot area includes acknowledgment slots that match the identifier of the corresponding subscribing process.

[0173] The first microservice node includes an event encapsulation module. This module encapsulates local events into transactional event messages carrying a global communication identifier, event sequence number, and a set of subscribing process identifiers, and sends these messages to the message broker node via the event bus. In one implementation, the first microservice node can also be configured with a local event communication log module. This module records transactional event messages according to the global communication identifier and event sequence number, and reads the transactional event message corresponding to the missing sequence number set upon receiving a missing event compensation event, to support targeted retransmission. This local event communication log module can be called by the event encapsulation module or implemented as an internal log storage area within the first microservice node.

[0174] The message broker node includes a subscription window management module, an acknowledgment vector management module, a missing event compensation module, a slot freezing module, a compensation type mapping module, a broker epoch maintenance module, and a communication closed-loop state machine module. The subscription window management module maintains corresponding subscription windows for each second microservice node and writes transaction event messages to the corresponding ordered message area or out-of-order temporary storage area based on the subscription window. The acknowledgment vector management module establishes acknowledgment vectors based on the subscription process identifier set, and the acknowledgment vector includes vector bits corresponding to the acknowledgment slot. The missing event compensation module extracts and generates a set of missing sequence numbers when it detects that there are event sequence numbers that have not been delivered consecutively in the subscription window, generates a missing event compensation event, and requests the first microservice node to resend the transaction event message only for the set of missing sequence numbers. The slot freezing module intercepts the update of the corresponding vector bit in the acknowledgment vector and generates a slot freeze compensation event when there are communication status acknowledgment messages with the same consumed event sequence number but different consumption fingerprints in the same acknowledgment slot. The broker epoch maintenance module maintains the current broker epoch identifier. The compensation type mapping module is configured with a compensation type mapping table and is used to generate and distribute reverse compensation event messages carrying the current agent epoch identifier based on the compensation type mapping table. The reverse compensation event messages include missing event compensation events and slot freeze compensation events. The communication closed-loop state machine module is used to establish the communication closed-loop state machine and update the communication closed-loop state of transaction event messages based on the communication closed-loop state machine.

[0175] In a further implementation, the message broker node also includes an acknowledgment slot crack signature module. This module generates an acknowledgment slot crack signature based on the global communication identifier, the acknowledgment slot identifier, the pending consumption sequence number in the subscription window, the consumed event sequence number in the communication status acknowledgment message, the consumption fingerprint, the corresponding vector bit status in the acknowledgment vector, and the current broker epoch identifier. The module then writes the acknowledgment slot crack signature into the crack signature field of the acknowledgment slot area. Furthermore, the module identifies out-of-order cracks, duplicate cracks, conflict cracks, and epoch cracks based on the acknowledgment slot crack signature, and sends the identification results to the compensation type mapping module and the communication closed-loop state machine module.

[0176] In a further implementation, the message broker node also includes a broker epoch dual-watermark echo lock module. This module generates a broker epoch sending watermark when generating a reverse compensation event message and writes the broker epoch sending watermark into the reverse compensation event message. The second microservice node generates its local watermark based on the current broker epoch identifier in its local epoch identifier cache and generates a compensation echo watermark when returning a compensation confirmation message. After receiving the compensation confirmation message, the broker epoch dual-watermark echo lock module verifies the compensation echo watermark and determines, based on the verification result, whether the communication closed-loop state machine module is allowed to continue executing state transitions.

[0177] In this embodiment, the event bus can be implemented using an inter-process message publish-subscribe channel. The message broker node receives transaction event messages published by the first microservice node through the event bus and sends missing event compensation events to the first microservice node through the reverse topic of the event bus. The inter-process message mailbox of the second microservice node can be implemented using a memory queue, a shared memory queue, or a logical queue in the message middleware. The sequential message area is used to store transaction event messages whose event sequence numbers meet the consumption conditions of the current subscription window; the out-of-order temporary storage area is used to store transaction event messages whose event sequence numbers are within the subscription window range but do not meet the consumption sequence numbers; the confirmation slot area is used to store communication status confirmation messages, mask slots, and invalid event slots. In the implementation of the confirmation slot crack signature module, the confirmation slot area is also used to store the crack signature field. In the implementation of the agent epoch double watermark echo lock module, the confirmation slot area is also used to store the compensation echo watermark field.

[0178] See Figure 1 and Figure 6In one specific deployment method, the first microservice node, message broker node, and second microservice node run as independent processes. The memory of the first microservice node process includes an event encapsulation buffer and a local event communication log index area. The memory of the message broker node process includes a subscription window array, an acknowledgment vector bitmap, a compensation type mapping table cache, a current broker epoch identifier register, and a communication closed-loop state machine instance. The memory of the second microservice node process includes an inter-process message mailbox and a local epoch identifier cache. The sequential message area and out-of-order temporary storage area can be implemented using a first-in-first-out queue, and the acknowledgment slot area can be implemented using a slot table addressed by global communication identifier and event sequence number. The local epoch identifier cache is used to store the current broker epoch identifier obtained by the second microservice node from transaction event messages or broker epoch update messages. In the further implementation of the confirmation slot crack signature module and the agent epoch double watermark echo lock module, the memory of the message broker node process also includes a crack signature cache area and an agent epoch sending watermark cache area, and the memory of the second microservice node process also includes a second microservice node local watermark cache area and a compensation echo watermark cache area.

[0179] To further illustrate the system's operation, taking two second microservice nodes as an example, the subscription window management module receives a transaction event message with event sequence number 205. The corresponding consumption sequence number for second microservice node A is 205, and the subscription window management module writes the transaction event message into the sequential message area of ​​second microservice node A. The corresponding consumption sequence number for second microservice node B is 203, and the window end sequence number is 208. The subscription window management module writes this transaction event message into the out-of-order temporary storage area of ​​second microservice node B and generates a missing sequence number set [203, 204]. The missing sequence number compensation module generates a missing event compensation event based on this missing sequence number set and sends it to the first microservice node via the event bus. The first microservice node reads the transaction event messages corresponding to event sequences 203 and 204 from its local event communication log and resends them. Through the above process, the system only performs targeted retransmission of transaction event messages corresponding to the missing sequence number set.

[0180] After consuming transaction event message with sequence number 205, the second microservice node A generates a communication status confirmation message and writes it to the confirmation slot area. The confirmation vector management module reads this communication status confirmation message and updates the corresponding vector bits in the confirmation vector according to the parsed status flag and the processed status flag. If there are communication status confirmation messages with the same consumed event sequence number and consumption fingerprint in the same confirmation slot, the compensation type mapping module generates an idempotent masking compensation event according to the compensation type mapping table. The second microservice node receiving the idempotent masking compensation event establishes a masking slot in the confirmation slot area and writes the corresponding consumption fingerprint into the masking slot to prevent transaction event messages with the same consumption fingerprint from entering the sequential message area.

[0181] If communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints exist in the same confirmation slot, the slot freezing module generates a slot freeze compensation event. The second microservice node corresponding to the slot freeze compensation event stops reading the transaction event message corresponding to the frozen slot identifier from the sequential message area and returns a slot freeze confirmation message to the freeze feedback topic. The confirmation vector management module sets the vector bit corresponding to the confirmation slot in the confirmation vector to a frozen state, and the communication closed-loop state machine module stops triggering state transitions based on the communication status confirmation message in that confirmation slot.

[0182] In the further implementation of the confirmation slot crack signature module, the module generates a confirmation slot crack signature after a communication status confirmation message is written to the confirmation slot. If there are communication status confirmation messages with the same consumed event number but different confirmation slot crack signatures in the same confirmation slot, the confirmation slot crack signature module identifies the confirmation slot as a conflict crack and outputs the crack identification result to the slot freezing module. The slot freezing module generates a slot freezing compensation event based on the crack identification result. If there are communication status confirmation messages with the same consumed event number and the same confirmation slot crack signature in the same confirmation slot, the confirmation slot crack signature module identifies the confirmation slot as a duplicate crack and outputs the crack identification result to the compensation type mapping module. The compensation type mapping module generates an idempotent shielding compensation event based on the crack identification result.

[0183] The proxy epoch maintenance module maintains the current proxy epoch identifier. When the message broker node is running normally, the current proxy epoch identifier can be "Epoch_NodeA_v2". When a primary / backup switch occurs in the message broker node, the proxy epoch maintenance module updates the current proxy epoch identifier to "Epoch_NodeB_v1". When the compensation type mapping module generates a reverse compensation event message, it writes the current proxy epoch identifier into the reverse compensation event message. After receiving the reverse compensation event message, the second microservice node compares the proxy epoch identifier carried in the reverse compensation event message with the current proxy epoch identifier stored in its local epoch identifier cache. If they match, the second microservice node processes the reverse compensation event message; if they do not match, the second microservice node creates a failure event slot in the acknowledgment slot area and writes the reverse compensation event message into the failure event slot.

[0184] In the further implementation of the proxy epoch dual watermark echo lock module, the proxy epoch dual watermark echo lock module synchronously generates a proxy epoch sending watermark when the compensation type mapping module generates a reverse compensation event message, and writes the proxy epoch sending watermark into the reverse compensation event message. After receiving the reverse compensation event message, the second microservice node generates a local watermark based on the current proxy epoch identifier in its local epoch identifier cache, and compares the second microservice node's local watermark with the proxy epoch sending watermark. If they match, the second microservice node processes the reverse compensation event message and returns a compensation confirmation message carrying the compensation echo watermark; if they do not match, the second microservice node writes the reverse compensation event message into the failure event slot. After receiving the compensation confirmation message, the proxy epoch dual watermark echo lock module verifies the compensation echo watermark; when the verification passes, the communication closed-loop state machine module continues to execute state transition; when the verification fails, the communication closed-loop state machine module does not unfreeze the corresponding confirmation slot.

[0185] See Figure 7 The system in this embodiment can also be implemented by a computer device. The computer device includes a processor, a memory, a communication interface, and a system bus. The processor is connected to the memory and the communication interface via the system bus. The memory stores program instructions executable by the processor. When the processor executes these instructions, the computer device performs event encapsulation, subscription window management, acknowledgment vector management, missing data compensation, slot freezing, compensation type mapping, proxy epoch maintenance, acknowledgment slot crack signature generation, proxy epoch double watermark echo lock verification, and communication closed-loop state machine update. The communication interface is used for sending and receiving messages with the event bus, the first microservice node, the message broker node, and the second microservice node.

[0186] In this embodiment, the communication closed-loop state machine module can instantiate the communication closed-loop state machine as a state table. Each row in the state table corresponds to a global communication identifier and an event sequence number. Fields include the current state, acknowledgment vector snapshot, current agent epoch identifier, last compensation type field, and last state update time. For example:

[0187] {

[0188] "Global_Msg_ID": "Tx-2025-0611-UUID890",

[0189] "Event_Seq": 105,

[0190] "Current_State": "Partial_Ack",

[0191] "Ack_Vector_Bitmap": "01 11",

[0192] "Current_Epoch_ID": "Epoch_NodeA_v2",

[0193] "Last_Comp_Type": "Slot_Freeze_Compensation",

[0194] "Last_Update_Time": "2025-06-11T10:30:16.205Z"

[0195] }

[0196] In the aforementioned state table, "01 11" indicates that the first confirmation slot corresponds to the processing completed state, and the second confirmation slot corresponds to the frozen state. After reading the confirmation vector snapshot, the communication closed-loop state machine module does not migrate the transaction event message to the closed-loop completed state. In the implementation of the proxy epoch double watermark echo lock module, the communication closed-loop state machine module also reads the compensation echo watermark verification result and maintains the current state without migrating to the closed-loop completed state if the compensation echo watermark verification fails.

[0197] To facilitate the explanation of the correspondence between the modules in the system, the correspondence between the modules and the processing actions in this embodiment is shown in Table 6.

[0198] Table 6. Correspondence between System Modules and Processing Actions

[0199] Event encapsulation module Local events Transaction event messages First microservice node process memory Local event communication log module Transaction event messages, missing sequence number set Transaction event message log recording The first microservice node process's memory or local log file Subscription window management module Transaction event messages, subscription window Sequential message area records or out-of-order temporary storage area records Message broker node process memory Confirmation Vector Management Module Communication status confirmation message, confirmation slot Confirm vector update result Message broker node process memory Missing Compensation Module Missing sequence number set Missing event compensation event Message broker node process memory Slot Freeze Module Confirmation message for conflict in slot Slot Freeze Compensation Event Message broker node process memory Compensation type mapping module Compensation type mapping table, confirmation status field Reverse compensation event message Message broker node process memory Agent Era Maintenance Module Primary / standby switchover event Current Agent Era Identifier Message broker node process memory Confirm slot crack signature module Confirm slot, confirm vector, consumption fingerprint, current agent epoch identifier Confirm slot crack signature and crack identification results Message broker node process memory Agent Era Dual Watermark Echo Lock Module Current Agent Era Identifier, Reverse Compensation Event Message, Compensation Confirmation Message Agent Era sends watermark and compensates for watermark verification results Message broker node process memory Communication closed-loop state machine module Confirmation vector, reverse compensation event message, and compensation echo watermark verification result Communication closed loop status Message broker node process memory

[0200] In this embodiment, each module of the system is configured around inter-program event communication between microservice nodes. Message objects, acknowledgment objects, and compensation objects all belong to message structures or state structures in inter-process communication. Therefore, the direct application area of ​​this embodiment is inter-program communication, and it is particularly suitable for event-driven asynchronous message communication state coordination scenarios in microservice architectures.

[0201] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. An event-driven distributed transaction eventual consistency coordination method, characterized in that, Inter-process event communication applied in a microservice architecture, wherein the microservice architecture includes a first microservice node, a message broker node, multiple second microservice nodes, and an event bus, each second microservice node runs as a subscribing process and is configured with an inter-process message mailbox, the inter-process message mailbox including a sequential message area, an out-of-order buffer area, and an acknowledgment slot area, the acknowledgment slot area including acknowledgment slots matching the identifier of the corresponding subscribing process, the method including: The first microservice node encapsulates local events into transactional event messages carrying a global communication identifier, an event sequence number, and a set of subscription process identifiers, and sends them to the message broker node via the event bus; The message broker node establishes an acknowledgment vector and a communication closed-loop state machine based on the subscription process identifier set. The acknowledgment vector includes vector bits corresponding to the acknowledgment slot and maintains a corresponding subscription window for each second microservice node. Based on the subscription window, the transaction event message is written to the corresponding sequential message area or out-of-order temporary storage area. When the message broker node detects that there are event sequence numbers that have not been delivered consecutively in the subscription window, it extracts and generates a set of missing sequence numbers, generates a missing event compensation event, and requests the first microservice node to resend the transaction event message only for the set of missing sequence numbers. The second microservice node consumes transaction event messages in the sequential message area and writes a communication status confirmation message carrying the consumed event sequence number and consumption fingerprint to the corresponding confirmation slot; When the message broker node has communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot, it intercepts the update of the corresponding vector bit in the confirmation vector and generates a slot freeze compensation event. The message broker node maintains the current broker epoch identifier, generates and distributes a reverse compensation event message carrying the current broker epoch identifier based on a pre-configured compensation type mapping table, the reverse compensation event message includes the missing event compensation event and the slot freeze compensation event, and updates the communication closed loop state of the transaction event message based on the communication closed loop state machine.

2. The event-driven distributed transaction eventual consistency coordination method according to claim 1, characterized in that, The transaction event message also includes a publishing process identifier, a communication phase marker, an event payload summary, and an acknowledgment return topic; the first microservice node establishes a log index in its local event communication log corresponding to the global communication identifier and the event sequence number, and writes the transaction event message into the log record corresponding to the log index.

3. The event-driven distributed transaction eventual consistency coordination method according to claim 1, characterized in that, The subscription window includes a consumption sequence number, a window start sequence number, and a window end sequence number; the message broker node maintains a corresponding subscription window for each second microservice node based on the global communication identifier, the subscription process identifier set, and the event sequence number.

4. The event-driven distributed transaction eventual consistency coordination method according to claim 3, characterized in that, When the event sequence number is equal to the pending consumption sequence number, the message broker node writes the transaction event message into the sequential message area; when the event sequence number is greater than the pending consumption sequence number but does not exceed the window end sequence number, the transaction event message is written into the out-of-order temporary storage area, and the event sequence numbers between the pending consumption sequence number and the event sequence number that have not been written into the corresponding inter-process message mailbox are written into the missing sequence number set.

5. The event-driven distributed transaction eventual consistency coordination method according to claim 4, characterized in that, When the missing sequence number set is empty, the message broker node transfers the transaction event messages in the out-of-order temporary storage area to the ordered message area in ascending order of event sequence number; when the missing sequence number set is not empty, the acknowledgment slot corresponding to the second microservice node with the non-continuously delivered event sequence number is marked as out-of-order missing.

6. The event-driven distributed transaction eventual consistency coordination method according to claim 2, characterized in that, The missing event compensation event includes the global communication identifier, the subscription process identifier corresponding to the second microservice node with the missing event sequence number, the set of missing sequence numbers, and the missing compensation feedback topic; The first microservice node reads the transaction event message corresponding to the missing sequence number set from the local event communication log according to the missing event compensation event, and resends the read transaction event message through the event bus.

7. The event-driven distributed transaction eventual consistency coordination method according to claim 3, characterized in that, The communication status confirmation message also includes the global communication identifier, the subscription process identifier, the parsing status flag, and the processing status flag; the parsing status flag includes parsing successful status and parsing abnormal status, and the processing status flag includes processing completed flag and processing abnormal flag; before generating the communication status confirmation message, the second microservice node compares the event sequence number of the transaction event message to be consumed with the consumption sequence number in the subscription window, and generates the consumption fingerprint when the two match.

8. The event-driven distributed transaction eventual consistency coordination method according to claim 7, characterized in that, When a message broker node has communication status confirmation messages with the same consumed event sequence number and consumption fingerprint in the same confirmation slot, it marks the corresponding confirmation slot as a duplicate confirmation state; when there are communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot, it marks the corresponding confirmation slot as a confirmation conflict state.

9. The event-driven distributed transaction eventual consistency coordination method according to claim 8, characterized in that, When the confirmation slot is marked as a confirmation conflict state, the message broker node sets the vector bit in the confirmation vector corresponding to the confirmation slot to a frozen state, so as to intercept the update of the corresponding vector bit and stop the state transition of the communication closed-loop state machine triggered by the communication status confirmation message in the confirmation slot.

10. An event-driven distributed transaction eventual consistency coordination system, characterized in that, It includes a first microservice node, a message broker node, multiple second microservice nodes, and an event bus; Each second microservice node runs as a subscription process and is configured with an inter-process message mailbox. The inter-process message mailbox includes a sequential message area, an out-of-order temporary storage area, and an acknowledgment slot area. The acknowledgment slot area includes acknowledgment slots that match the identifier of the corresponding subscription process. The first microservice node includes an event encapsulation module, which is used to encapsulate local events into transaction event messages carrying a global communication identifier, an event sequence number, and a set of subscription process identifiers, and send them to the message broker node via the event bus; The message broker node includes a subscription window management module, an acknowledgment vector management module, a missing compensation module, a slot freezing module, a compensation type mapping module, a broker epoch maintenance module, and a communication closed-loop state machine module. The subscription window management module is used to maintain a corresponding subscription window for each second microservice node, and write the transaction event message into the corresponding sequential message area or out-of-order temporary storage area based on the subscription window; The confirmation vector management module is used to establish a confirmation vector based on the subscription process identifier set, wherein the confirmation vector includes vector bits corresponding to the confirmation slot; The missing event compensation module is used to extract and generate a set of missing event numbers when it detects that there are event numbers that have not been delivered consecutively in the subscription window, generate a missing event compensation event, and request the first microservice node to resend the transaction event message only for the set of missing event numbers. The second microservice node is used to consume transaction event messages in the sequential message area and write a communication status confirmation message carrying the consumed event sequence number and consumption fingerprint to the corresponding confirmation slot; The slot freezing module is used to intercept the update of the corresponding vector bit in the confirmation vector and generate a slot freezing compensation event when there are communication status confirmation messages with the same consumed event sequence number but different consumption fingerprints in the same confirmation slot. The proxy epoch maintenance module is used to maintain the current proxy epoch identifier; The compensation type mapping module is configured with a compensation type mapping table and is used to generate and distribute a reverse compensation event message carrying the current agent epoch identifier based on the compensation type mapping table. The reverse compensation event message includes the missing event compensation event and the slot freeze compensation event. The communication closed-loop state machine module is used to establish a communication closed-loop state machine and update the communication closed-loop state of the transaction event message based on the communication closed-loop state machine.

Images