訂單自動確認或取消設計方案-有解無憂

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

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

簡介

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/540360.html

標籤：其他

上一篇：django框架(部分講解)

下一篇：hibernate validate工具，小心你的姿勢不對