訂單自動確認或取消設計方案

訂單自動確認或取消設計方案

 

　　　　前不見古人，後不見來者。念天地之悠悠，獨愴然而涕下。

簡介

系統訂單自動確認或取消的設計方案，最常見的一個業務比如N天后自動確認訂單，達到動態修改訂單狀態的目的。大多數項目採用的都是如下兩種方案。

• 方案1：使用傳統的數據庫如MySQL，通過輪詢來判斷數據庫表中訂單的狀態。該方案性能較低，且增加了IO次數。
• 方案2：使用 Redis 給訂單設置N天過期時間，通過判斷 Redis 中是否還有該訂單來決定訂單是否已經完成。該方案比方案1好點，但相較於消息的延遲推送性能較低，且需要把 Redis 中數據都從內存中持久化到硬盤。

上面方兩種傳統解決方案會降低了系統的整體性能和吞吐量，往往不夠支持龐大的系統如京東、天貓、亞馬遜或者12306等系統。這時可以考慮採用MQ，平時MQ用的較多的就是業務解耦、前端削峯（秒殺系統）、高可用性和順序消息。除此之外，RabbitMQ還支持定時消息和延遲消息，Broker中有定時消息的機制，消息發送到Broker中，不會立即被Consumer消費，會等到一定的時間才被消費。延遲消息也是一樣，延遲一定時間之後纔會被Consumer消費。

體系較爲龐大的項目一般會採用RabbitMQ的消息延遲消推送來實現。

• 如京東N天后自動確認收貨。在商品被簽收後，物流系統會在N天后延時發送一個消息給支付系統，通知支付系統將款打給商家，這個過程持續七天，就是使用了消息中間件的延遲推送功能。
• 如 12306 購票支付確認頁面。選票後點擊確定會跳轉倒支付頁面，該頁面會帶有倒計時，代表着 30 分鐘內訂單不確認的話將會自動取消訂單。在下訂單那一刻，購票業務系統就會發送一個延時消息給訂單系統，setDelay延時30分鐘，通知訂單系統訂單未完成，如果用戶在30分鐘內完成了訂單的支付操作，則可以通過邏輯代碼判斷來忽略掉收到的消息。

消息延遲推送的實現

首先按照常規的手段創建交換機和消息隊列，配置生產者和消費者等基礎信息。不同的是，在 Exchange 的聲明中設置 exchange.setDelayed(true)來開啓延遲隊列。

 exchange.setDelayed(true)

或設置交換機支持延遲隊列推送。

1     @Bean
2     public TopicExchange lazyExchange(){
3         //Map<String, Object> pros = new HashMap<>();
4         //設置交換機支持延遲消息推送
5         //pros.put("x-delayed-message", "topic");
6         TopicExchange exchange = new TopicExchange(LAZY_EXCHANGE, true, false, pros);
7         exchange.setDelayed(true);
8         return exchange;
9     }

然後，發送消息時指定延遲推送的時間就可以實現消息延遲推送了。

1 　　public Message postProcessMessage(Message message) throws AmqpException {
2                 //設置消息持久化
3                 message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
4                 //message.getMessageProperties().setHeader("x-delay", "6000");
5                 message.getMessageProperties().setDelay(6000);  // 指定延遲推送的時間
6 　　　　　　return message; 7 }

 

 

 

 

 

前不見古人

　　　　後不見來者

　　　　　　　　　　念天地之悠悠

　　　　　　　　　　　　　　　獨愴然而涕下