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

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

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

簡介

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