What is the message queue, for white view: http://developer.51cto.com/art/201904/595020.htm
rabbitmq face questions: https://blog.csdn.net/qq_42629110/article/details/84965084
The use of message queues to avoid distributed transactions
If you look at life, then life scene has given us a lot of tips.
For example, after the famous Beijing Yao Kee Chaogan point Chaogan and paid for, they do not directly point to your Chaogan you often give you a small ticket, and then let you take a small vote shipping line up to get into the area.
Why do they want to pay for and pick up two separate actions it? For many reasons, one very important reason is that in order to make their reception capacity enhancement (higher concurrency).
Or return to our problem, as long as this small ticket, you are finally able to get the Chaogan. Similarly transfer services, too, when the user account A net of 10,000,
we just generate a certificate (message) can be read, this certificate (news) "allows users to B accounts increased 10,000," as long as the voucher (news ) can be reliably saved,
we can finally take this voucher (news) allows users to B accounts increased 10,000, that we can rely on the certificate (message) to complete the final consistency.
1 How reliable Save the document (message )
There are two ways:
1.1 coupling mode with the message service
User A is debited while simultaneously recording the message data, the message data and service data stored in the same database instances (called message-table record message);
|
1
2
3
4
5
|
<span style=
"color: #000000;"
>Begin transaction
update A
set
amount</span>=amount-10000
where
userId=1<span style=
"color: #000000;"
>;
insert
into
message(userId, amount,status) values(</span>1, 10000, 1<span style=
"color: #000000;"
>);
End transaction
commit;</span>
|
As long as the above transactions to ensure that the user account A money deducted, the message will be able to survive.
When the above-mentioned transaction commits successfully, we notice this message through real-time messaging service user B, user B successfully treated successfully send a reply message, the message data after deletion of the article A user received a reply.
1.2 decoupled manner with the message service
Such that the above-described manner saved message data and message service data tightly coupled together, Architecturally inelegant, and likely to cause other problems. To decouple, can be used in the following manner.
1) A user charges before a transaction is committed, to request real-time messaging service to send messages, instant messaging service messages only record data, without actually sending the transaction will be submitted only after the message is sent successfully;
2) When the user A debit transaction is committed successfully, send an acknowledgment to the real-time messaging service. Only after receiving confirmation instruction, real-time messaging service really sending the message;
3) When the user A debit transaction rollback failure to submit, to cancel sending real-time messaging service. After obtaining the transmission cancellation command, the message will not be transmitted;
4) For those unacknowledged message or a cancel message, the user need state of the timing to the system A query message is a message the state confirmation and update the system. Why this step,
for example: Suppose the second step after the user A debit transaction is successfully submitted, the system hung up, then the status message has not been updated to "send confirmation", thereby causing the message can not be sent.
Advantages: independently storing message data, reducing the coupling between the service system and the message system;
Disadvantages: a need to send two request message; service message processing services need to implement the interface state check back.
2 How to solve the problem of duplicate messages delivered
There is also a very serious problem is the repeated message delivery to our customers A transfer to user B, for example, if the same message is repeated twice delivered, then we will increase the user account B 20,000 instead of 10,000.
Why repeat the same message will be delivered? For example, the user B finished processing the message msg, sent a message to the user A successful process, under normal circumstances should you want to delete user A message msg, but this time if user A tragedy hung up,
a look at the message msg is still after the restart, it will continue to send the message msg.
The solution is simple, the user B side to increase messaging application state table (message_apply), it is a popular books, records messages for consumption, each to a message,
before the actual execution, go messaging application status table query again, if the note is found duplicate messages can be discarded, if not found before execution, and inserted into the message application state table (the same transaction)
|
1
2
3
4
5
6
7
8
|
for
each msg
in
queue
Begin transaction
select
count(*)
as
cnt
from
message_apply
where
msg_id=msg.msg_id;
if
cnt==0 then
update B
set
amount=amount+10000
where
userId=1;
insert
into
message_apply(msg_id) values(msg.msg_id);
End transaction
commit;
|