Read the final consistency solution for reliable messages (standalone messaging service)

Preface

In the last study, "reliable message final consistency solution" (local messaging service) I introduced the final consistency of distributed transactions through the local messaging service, and finally the pros and cons of this implementation, and now we introduce the solution of how to achieve the final consistency of distributed transactions through the stand-alone messaging service. Body

In distributed transactions, there are many theories, such as cap,base, and solutions such as 2PC,TCC, which I will not speak directly into the subject.

First of all, suppose a scene, when we buy things, we need to buckle inventory, for example, you buy a computer, the number of this computer in inventory should be reduced by 1, in fact, many of the distributed transactions are not required strong consistency, only need to meet the final consistency, like this scenario to meet the final consistency on it, You buy a computer, in a period of time this computer's inventory will be reduced by 1, do not require you just order to reduce the inventory immediately.

In accordance with the urine of the microservices, the above scenario involves order service ordering operations and inventory service buckle inventory operations, and related to the order base and inventory database two databases, so you cannot use local transactions to solve the problem.

The following is a picture of this, I re-draw, on the basis of the dragon Fruit added to the label, this can be better to describe the entire reliable message final consistency scheme. The order service can be regarded as the active application system, and the inventory service is regarded as the passive application system.
The user orders, the active party applies the pre-send message to the message service subsystem. The message service subsystem stores pre-sent messages. Returns the result of storing a pre-sent message. If the result returned by step 3rd is successful, the business operation is performed, otherwise it is not executed. After the business operation succeeds, the message service subsystem is called to confirm the send message. Sends a pre-sent message stored in the Message service library and updates the message's status to sent (but not consumed). Message middleware sends messages to consumer applications. The consumer app invokes the passive-party app service. The passive side application returns the result to the consumer application. The consumer application ACK this message to the message middleware and confirms to the message service subsystem that it is consuming the message successfully, letting the message service subsystem delete the message or set the status to a successful consumption. The message recovery system periodically checks the message data to see if there is a timeout message for the sent status, which is not the kind of message that has been successfully consumed. The active application system should provide a query interface to query whether the business data corresponding to the message is handled successfully for a message. If the business data is in a successful state, then the acknowledgement is called again and the message is sent, entering the 6th step. If the business data is processing failed, then the message service subsystem is called to delete the message data.

If the system is consistent in the event of an error, you can refer to the "reliable Message final consistency scheme" (Local messaging service)

summed up in fact, as long as the message data persisted, I assume that the back will be consumed, even if behind a pile of things, but we put off the service to start all again, this message will be consumed, will not be lost, can guarantee eventual consistency. Advantages Message Service independent deployment, independent maintenance, independent scaling. Message stores can select different database integration implementations on demand. Messaging services can be shared by the same usage scenarios, reducing the cost of repeating construction message services. The reliability of message data is realized from the angle of design and development of application (distributed service), and the reliability of message data is not dependent on message middleware, which weakens the dependence on the characteristics of message middleware. It reduces the coupling between the business system and the message system, and facilitates the extended maintenance of the system. The disadvantage of sending a message requires two requests at a time. The active application needs to provide more query interfaces.