Contact at the end of last year RocketMQ, It's mainly because of the official announcement that the information will reach , Project related to payment , adopt Restful
api Receiving order repository + Push MQ, Paid by the consumer . Later, it was found that even if the message must reach , But the news is not necessarily 100% Sent successfully , So how to judge the success of message sending becomes a pit again .

Message sending results SendStatus branch 4 species SEND_OK,FLUSH_DISK_TIMEOUT,FLUSH_SLAVE_TIMEOUT,SLAVE_NOT_AVAILABLE, In theory, if broker Configure synchronous disk dropping + Synchronous double write , Then only SEND_OK To clearly identify the success of sending , Other status is send failure , But actually the receipt is other 3 Messages are sent successfully in all States . Therefore, if the message is sent without exception, the message will be sent successfully , However, in the later high concurrency test, the message sending exception occurred , But the consumer got the message
, Tried 2 Solutions , Finally, the scheme is used 2:

programme 1: If the message is sent abnormally , Data rollback , At the same time, add message confirmation at the consumer end , For example, whether the order is received , But there's a problem , be on the cards consumer Message receiving speed ratio data commit Faster , Then it will appear that the consumer first judges that the data is no longer in the database , Then the data is inserted , So the plan 1 Poor performance and logic ,pass.

programme 2( recommend )
:api Stock in after receiving order , Regardless of MQ Whether the message is sent as , All returned successfully , No rollback required . Add monitor , Time out not consumed ( Message sending failed ) Order reissue message for , This scheme is relatively good. You can use the default configuration to send messages , It is not necessary to increase the limit of message sending retry times and retry timeout , Receive orders as quickly as possible + Repository + Push message . Message sending failure is an extreme case , Therefore, the monitoring task is not large and the execution logic is very simple , Just send a replacement message .

It is recommended that whatever is used MQ, The test results of message throughput and message must reach are bullshit , With business logic, there will be all kinds of holes , If you want to ensure that the message must arrive or be sent , So the plan 2 Monitor in is an essential module .

Technology
©2019-2020 Toolsou All rights reserved,
JS How to operate java Realize the function of grabbing red packets C Language programming to find a student's grade The United Nations 《 Glory of Kings 》 Please go to the studio : To save the earth Dialogue between apple and Nissan suspended ,Apple Car How's it going ?CSS architecture design China's longest high speed rail officially opened ! The fastest way to finish the race 30.5 hour First knowledge MySQL Comprehensive review ( dried food )2021 year 1 Monthly programmer salary statistics , average 14915 element How to use it quickly html and css Write static page