Explore implementing reliable messaging services

Introduction

Distributed transactions are often the pain point of service-oriented. Many scenarios avoid distributed transactions through business, but there are still some scenarios that must rely on distributed transactions. Let’s talk about how to handle distributed transactions

1 Common solutions

There are many ways to solve distributed transaction problems, and there are many blogs on the Internet that provide various solutions. To sum up, it can generally be divided into the following two methods: 1. Two-Phase Commit (2PC for short): This is a common distributed transaction solution. In this method, the coordinator node is responsible for coordinating the operations of the participant nodes and ensuring that all nodes reach an agreement when committing or rolling back.

Rigid distributed transactions and two-phase commit are a mechanism to achieve strong consistency. Rigid distributed transactions refer to a series of operations performed by multiple participant nodes in a distributed system that need to ensure atomicity, that is, either all succeed or all fail. This mechanism requires all participant nodes to follow the same protocol during transaction execution and implement the transaction

through the guidance of the coordinator node.

Flexible distributed transactions are a method of handling transactions in distributed systems. It adopts the best-effort commit strategy, that is, it tries its best to complete the transaction submission, but also allows some operations to fail. In flexible distributed transactions, the TCC (Try-Confirm-Cancel) mode is usually used to implement transaction management. The TCC model decomposes transactions into three phases: try, confirm and cancel

First solve the prerequisite guarantee for distributed transactions: the interface must be idempotent to prevent repeated sending of messages from affecting the business

2 Reliable message system design (this feels good and relatively simple, so I’ll share it)

As shown above

Start execution For example:

try{
if(prepare()) { //Pre-send phase doService(); //Execute business logic
updateMsgStatus();//Update message to confirm status
}
}

1 Pre-sending the message, try phase, if the pre-sending message fails, the business has not been executed yet, so systems A and B are still consistent and no processing is required

This is easy to understand

2 The pre-sent message is successful and the business logic starts to be executed. If the execution is successful, the status of the updated pre-sent message will be changed to confirmed sending. If the business logic execution fails at this time, the pre-sent message will not be updated with the new status. At this time, the message confirmation system will start working, and go back to the business system 1 to check the message status. If it is found that the business execution failed, it will be updated. Pre-send status to failed status.

3 If at this time, the business execution is successful and the message is updated to confirm sending, then it is ok and perfect. If the message update fails, the message confirmation system will still check the status and update whether the message is deleted or confirmed to be sent.

4 The messager starts consuming

1> For example, if consumption fails and an inconsistency occurs, the message recovery system detects the message status and resends the message

2>If the execution of the business fails, the message will not be confirmed. The message recovery system will still detect the message status and resend the message

3>If the ask fails, the above logic should be used to resend the appeal. Of course, there is a limit to the number of resends. It cannot be sent all the time. If it exceeds the maximum number of times, it will enter the dead letter queue and wait for manual intervention.

4> If the ask is successful, the message will be consumed successfully, which is perfect and solves the problem of reliable message service

三 Try to submit

This is relatively simple. Submit failed messages repeatedly to ensure successful message push in some scenarios with weak real-time performance.

For example, when a transaction is completed, a third-party message will be pushed. At this time you can use effort submission

The article is reprinted from Open Source China Community [http://www.oschina.net]

The above is the detailed content of Explore implementing reliable messaging services. For more information, please follow other related articles on the PHP Chinese website!