RocketMQ message sequence sending and consumption issues

Accident scene analysis:

Due to the launch of innovative business products, operating products want to stimulate users through some activities, using registration invitation mechanism to get points related activities. Considering that there may be other possible activities to distribute points in the future, so when designing, the mq message mode is used to issue points, asynchronous decoupling, and can ensure the final consistency of the data. Considering that there may be concurrent operations in the
calculation of user points, two solutions are thought of: 1. A distributed lock method is used to calculate user points, and the same user operation is kept synchronized
. 2. The inherent advantage of using queues, FIFO As long as the points of the same user are placed in the same queue, the queue can be consumed in sequence to ensure that the calculation of user points is synchronized.
After thinking and screening, I finally decided to use the RocketMQ queue FIFO to calculate the points, so I have fallen into the quagmire unconsciously. Because the MQ message processing packaged by the company did not do the sequential sending of messages and the related encapsulation of the message, he re-encapsulated a layer of sequential sending methods on the company's public method, using the user's unique Id hash to choose the remaining choice Queue, to ensure that the same user's credit message can be sent to the same queue, and then assume that MQ consumes a message SUCCESSafter consuming one and then consume other queue messages. So the test is completed after the development is completed. When the result test is done in the concurrent test, the user points calculation is always less than the actual number of points issued. So, began to fall into contemplation ......

Trouble shooting:

So I began to doubt my code problem, check it, check it ... There is no problem with logic. So began to guess:

1. 难道是消息发送丢失?或者发送的时候不在同一个队列?
So violently print the message sending log. After checking the log, it is found that the message sending and consumption are all normal. And according to the Hash algorithm, the same person is also in the same queue, but why is there concurrent computing?
2. 消息消费的时候是并发消费的?
As the previous proficiency in RocketMq is not enough, it is not clear that the original sequential consumption also needs to be guaranteed by the method of using MessageListenerOrderlythis listen consumption to ensure the sequential consumption of messages DefaultMessageListener. The broker does not fully guarantee the order of message consumption, it can only guarantee the order of messages sent! , As long as it is sent sequentially, and then ensure that a thread only consumes messages on a queue, then he is ordered.

solution:

For the company's MQ method encapsulation, it did a secondary encapsulation using the user's unique ID Hashcoderesidual selection queue, and used MessageListenerOrderlymonitoring and consuming messages to ensure the order of message consumption. The test was solved by concurrent calculation, and the integral calculation problem was completely correct.

Insert picture description here

Published 41 original articles · Liked 14 · Visitors 10,000+

Guess you like

Origin blog.csdn.net/Yunwei_Zheng/article/details/104018723