eventual consistency
Eventual consistency refers to the state of the two systems being consistent, either succeeding or both failing. Of course there is 时间限制. In theory, the sooner the better, but in fact, under various abnormal conditions, there may be a certain delay in reaching the final consistent state, but the final state of the two systems is the same.
For this 时间限制, personal understanding:
1. First of all, it is related to the system, and the system does not require high real-time performance.
2. The time is guaranteed to be within the acceptable range, otherwise the user experience will not be good
Evolution of Distributed Transaction Based on Reliable Message Service
process:
1. System A processes tasks
2. After processing, sends messages to message middleware
3. Message persistence
4. Messages are delivered to system B
5. System processes task B
question:
1. If the processing task of system A is completed, the message sending fails
2. The message delivery fails due to network reasons
3. The processing system B fails to process the task
solution:
For problem 1, it is required that the upstream system information must be successfully sent
After the processing task of system A is completed, the information to be sent is recorded locally. A scheduled task constantly checks whether the transmission is successful, and if the transmission is successful, the status modification will be recorded.
For problem 2, it is necessary to ensure that the message is successfully consumed by the downstream system
If the message is lost during the delivery process, or the acknowledgment response of the message is lost on the way back, the message middleware will re-deliver after waiting for the acknowledgment response timeout until the downstream consumer returns a successful consumption response.
For problem 3, a retry mechanism for task B is required
When the task processing fails, it returns to the message middleware failure, on the basis of solving the second problem. The message will be sent repeatedly, that is, task B will retry
question
1. Due to network problems, the message delivery timed out, and the message mediator retried and sent another message. At this point, the system receives the first message and processes task B. A second message is received and task B is processed. Task B is executed 2 times
2. The processing of task B has always failed, and the message has been retried to send?
For problem 1, the message needs to be idempotent
Before task B processes the message, it first checks whether the message has been consumed. If it is not consumed, task B is successfully processed and the message is recorded. If the message has been consumed, directly return the response success
For problem 2, limit the retry of the task and log the message
The execution of task B keeps failing, indicating that there is a problem with the program, and there is no need to retry. Record the message, (waiting for manual processing, or re-executing the scheduled task)
final system
Summary: Eventual consistency, mainly in the way of "recording" and "compensation".
Before doing all uncertain things, record things first, then do uncertain things, the result may be: success, failure or uncertainty, "uncertain" (such as timeout, etc.) can be equivalent to failure . If you succeed, you can clean up the recorded things. For failures and uncertainties, you can rely on timed tasks to re-do all the failed things until you succeed.