NOTE
2.8 Reliable-Message Eventual-Consistency Implementation: Local Message Table
1. What Is a Local Message Table - Use two transactions, placing an order and then adding points, as an example. The ordering service is Service A and the points service is Service B. 1. Service A executes ordering logic. 2. After Service A successfully places the order, it sends a message to MQ. 3. Service B consumes the message and processes its local transaction.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is a Local Message Table?

Use two transactions, placing an order and then adding points, as an example.
The ordering service is Service A, and the points service is Service B.
- Service A executes ordering logic.
begin transaction;
1. place order
2. insert log into local message table
commit transaction;
- After Service A successfully places the order, it sends a message to MQ.
- Service B consumes the message and processes its local transaction.
begin transaction;
1. insert message into local message table
2. add points
commit transaction;
- After Service B executes successfully, update the status in the local message table.
- Service B message-table status [ZooKeeper can be used for decoupling].
- Service A periodically scans the message table and sends unprocessed messages to MQ.
2. Characteristics
Depends on MQ and a database. For failed messages, the initiator can write a scheduled dispatcher to poll and resend them.
2PC vs Local Message Table
The local message table introduces MQ and executes distributed transactions asynchronously, improving throughput.
Discussion
Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub