Solution for processing overtime orders (Overtime unpaid)

1. Overtime unpaid order processing

1.1 Demand analysis

Orders that have not been paid beyond the time limit , We need to deal with overtime orders ： First call wechat payment api, Query the payment status of this order . Call to close the order if not paid api, And modify the order status to closed , And roll back the inventory . If the order has been paid , Then do the compensation operation （ Modify order status and records ）.

1.2 Realize the idea

Implementation steps :

1. When generating an order ( The creation time of the order is recorded in the table )

2. According to the creation time of the order 30 Minutes , If the order is not paid

3. Put the order generation message into the dead letter queue

4. Consume the messages in the dead letter queue : Delete the unpaid orders in the database , Need to modify the inventory of goods

How to get orders that exceed the time limit ？ We can use delayed message queues （ Dead letter queue ） To achieve .

The so-called delayed message queue , That is, messages sent by message producers will not be consumed immediately , Instead, it can be consumed after the set time .

We can send a delay message when the order is created , Message is order number , The system will retrieve this message after a limited time , Then query the payment status of the order , Make corresponding treatment according to the results .

1.3 rabbitmq Delay message

Use RabbitMQ To implement deferred messages, you must first understand RabbitMQ Two concepts of ： News TTL And dead letter Exchange, Through the combination of the two to achieve the above requirements .

1.3.1 News TTL（Time To Live）

News TTL It's the survival time of the message .RabbitMQ You can set the queue and message separately TTL. Setting the queue is the retention time when the queue has no consumers , You can also make separate settings for each individual message . Beyond this time , We think the news is dead , Call it a dead letter .

Let's create a queue queue.temp, stay Arguments Add x-message-ttl by 5000 （ In milliseconds ）, Then every message that enters this queue is 5 Seconds later .

1.3.2 A dead letter exchanger Dead Letter Exchanges

A message satisfies the following conditions , It will enter the dead letter switch , Remember, this is the switch, not the queue , A switch can correspond to many queues .

（1） A message was Consumer Rejected , also reject Method parameters requeue yes false. That is to say, it will not be put in the queue again , Used by other consumers .

（2） From the above news TTL here we are , The news is out of date .

（3） The length limit of the queue is full . Messages in the front row will be discarded or thrown on the dead letter switch .

Dead Letter Exchange In fact, it is a kind of ordinary exchange, And create other exchange There is no difference . Just in a certain setting Dead Letter Exchange There are messages out of date in the queue of , Will automatically trigger message forwarding , Send to Dead Letter Exchange In the middle .

We can now test the delay queue .

（1） Create a dead letter exchange exchange.ordertimeout （fanout）

（2） Create a queue queue.ordertimeout

（3） Establish a dead letter exchange exchange.ordertimeout And queues queue.ordertimeout Binding between

（4） Create a queue queue.ordercreate,Arguments add to

x-message-ttl=10000

x-dead-letter-exchange： exchange.ordertimeout

（5） test ： towards queue.ordercreate Queue add message , wait for 10 Message from in seconds queue.ordercreate The queue disappears ,

1.3.3 Delayed message processing

From message queue queue.ordertimeout Extract messages from , Execute order deletion