First of all, make it clear , Message retry only for cluster consumption mode , Broadcast consumption has no message retry feature , After consumption failure , Will only continue to consume the next message . And that's why we've repeatedly stressed that , It is recommended to use cluster consumption mode , Its message retry feature can bring great convenience to developers .
So what is message retry ? In a nutshell , When consumers fail to consume information ,broker The message will be redelivered , Until consumption is successful . stay RocketMQ
in , When consumers use cluster consumption mode , After the consumer receives the message and performs the corresponding logical processing , Finally, a status value should be returned to broker. such broker
To know whether the consumption is successful , Need to resend message . in other words , We can tell by setting the status value returned broker Resend message or not .
Come here , Maybe you have a question , So if the message itself is a piece of dirty data , Even if you spend 100 No success in consumption , Do you want to try again ? actually RocketMQ
It's not going to be unlimited , Default maximum retries per message 16 second , The interval time of each retry is shown in the table below ：
Retries Interval between retries
1 10 second
2 30 second
3 1 minute
4 2 minute
5 3 minute
6 4 minute
7 5 minute
8 6 minute
9 7 minute
10 8 minute
11 9 minute
12 10 minute
13 20 minute
14 30 minute
15 1 hour
16 2 hour
Then if the message is retried 16
How to deal with the failure of consumption ? Then the message will not be delivered to consumers , Instead, put the message in the corresponding dead letter queue . At this time, we need to do some manual compensation for the dead letter queue messages , Because these messages may have their own problems , It may also be related to the service called by consumption logic, etc , So it needs to be handled after manual judgment .
I don't know if you have a question here , What kind of situation is consumption failure ? It can be divided into 3 Situation ：
The first two situations are easy to understand , It is the setting status value mentioned above , in other words , Just consumer return
ConsumeConcurrentlyStatus.RECONSUME_LATER perhaps null, It's like telling broker
say , I failed to consume the news , You deliver it to me again . In the case of throwing an exception , Just throw an exception where you handle the consumption logic , that broker
And re deliver the message . Pay attention , If the exception is caught , Message retry will not occur .
First of all, what is consumption idempotent ? In short, it is the result of processing a message , No matter how many times this message is processed , The end result is the same . for instance , You receive a message to update the price of a product to 6.8
element , So when this message is executed 1 second , Or execution 100 second , Finally, the price of the product in the database is 6.8 element , This is called idempotent .
So why does consumption need idempotent ? Because in actual use , Especially when the network is unstable ,RocketMQ There may be duplicate messages for , There are two situations ：
Duplicate message when sending ;
Duplicate message at delivery ;
The first is the scenario where the producer sends the message , Message successfully sent to broker , But at this time, there may be network outage or producer downtime , cause broker
Response sent back failed . At this time, the producer does not receive a response , Consider message sending failed , So try sending the message to broker. thus ,broker
I'll get another message with the same content , Finally, consumers receive two messages with the same content .
The second is the scenario of consumer consumption information , The message has been delivered to the consumer and completed the consumption logic processing , When consumers give broker Network flicker may occur when feedback consumption status .broker
Can't receive consumers' consumption status , In order to ensure the semantics of consumption at least once ,broker Messages that have been processed before attempting to post again after network recovery , Finally, consumers receive two messages with the same content .
Of course, for some scenarios where message repetition is allowed , You don't have to worry about consumption idempotent . But for those business scenarios where message duplication is not allowed , Processing suggestion is the basis of idempotent processing through the unique identification on the business .
Message retry , Ensure the fault tolerance of consumption message , Even if consumption fails , There's no need for developers to write their own code to compensate , Greatly improved development efficiency , It's also RocketMQ Compared with others MQ
A very good feature of . The consumption idempotent is mainly for those scenarios where message repetition is not allowed , Most of them MQ
All need idempotent processing , It's code logic or business needs , The best way to deal with this problem is to use the unique business identifier as the basis for idempotent processing .