Eventually consistent implementation of distributed transactions

Preface

This article is "Understanding of Distributed Transactions" : Implementation of Eventual Consistency of Distributed Transactions.

It is still the e-commerce requirement, a business scenario after the order payment is completed, there are the following operations:

1. Change the status of the order to "paid"
2. Deduction of commodity inventory
3. Add points to members
4. Create an outbound order to notify the warehouse to deliver goods

We use the eventual consistency scheme to achieve it.

What is final consistency?

Literally, guarantees the final consistency of the data .

In order to reduce the system cost, if an intermediate node fails to process, other nodes generally will not automatically roll back. Instead, the failed data is processed through a retry mechanism and manual participation to ensure the final consistency of the data.

Implementation plan

Use local message table + background task + message queue + interface idempotence.

local message table the corresponding service database. This table stores the messages generated by the service. The local transaction ensures the consistency of the service data and the message data, for example: msg_published and msg_received indicate the release message table And the received message table, there will be a status in the message table to identify whether the service is executed successfully.

Background task : When there is business information that has failed to execute in the message table, the background task will be retried according to the configured retry strategy. For example, the retry strategy is that when the message is sent and consumed, it will be retried immediately 3 Times, after 3 times, it will enter the retry polling; the retry will start 4 minutes after the failure of sending and consuming the message, this is to avoid possible problems caused by the delay of setting the message status; the follow-up will be after every 1 minute Retry once. The default maximum number of retries is 50 times. When it reaches 50 times, there will be no retry. You will be notified by email/Wechat/Dingding/SMS to process manually. You need to consider the message drop when notifying. noise.

message queue : use message queues for calls between cross-services to achieve service decoupling.

Interface idempotence : The interface needs to ensure that the results of one request or multiple requests initiated by the same operation must be consistent.

Code

Recommend a C# open source project CAP , you can refer to it.

This project only supports C# code to integrate, if it is other languages, you can refer to its design ideas, and then carry out a simple implementation.

summary

This article is purely an introduction, there are problems, criticisms and corrections are welcome.

Do you have a better solution? Welcome to leave a message~

Recommended reading

• Answer two frequently asked code writing questions
• According to user feedback, two new functions are added to the open source project go-gin-api
• Regarding the processing of the circulation of the e-commerce system order status, share my technical solution (with source code)
• How do I write Git Commit message?