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 .