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

濤姐濤哥發表於2022-12-20

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

 

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

簡介

系統訂單自動確認或取消的設計方案，最常見的一個業務比如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 }

 

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

 

相關文章