RabbitMQ实现订单超时设计思路、以及在订单过期临界点支付成功如何处理

已于 2022-12-07 11:23:11 修改
阅读量3.5k 收藏 13
点赞数 1
CC 4.0 BY-SA版权
分类专栏： MQ 文章标签： rabbitmq
于 2022-12-07 11:17:46 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/hkl_Forever/article/details/128216981
本文介绍了使用RabbitMQ的延时队列实现订单超时自动关闭的设计，包括订单状态、支付状态和库存管理。讨论了用户在订单即将过期时支付成功的情况，提出两种处理方案，并强调开发需关注业务与技术的结合。

场景：
我们知道用 RabbitMQ 的延时队列可以实现用户下单后在 xxx 时间内未支付，需要自动关闭订单。但如果用户在订单即将过期的最后一秒支付成功、那么这笔订单算不算正常下单？要不要释放库存？

一、下单未支付超时自动关闭订单设计思路

1、以 30分钟 为例，订单表必须的字段

订单状态、订单支付状态、订单过期时间、库存是否释放、库存释放时间

【1】订单状态：已下单、待出库、运输中、派送中、已取消、已关闭等
【2】订单支付状态：已支付、未支付
【3】订单过期时间：此字段可返回给前端，用于倒计时的起点。取值为用户下单时候订单信息落库时间+30分钟，下单接口可使用异步线程同时把订单信息落库、丢入消息队列
【4】库存是否释放：是、否
【5】库存释放时间：此字段要晚于订单过期时间 1 到 2 分钟，避免订单过期后库存立刻释放而被其他订单冻结，用于临界点支付成功的缓冲时间 

二、用户在订单即将超时的最后一秒支付成功，这笔订单如何处理？

1、此问题需要开发和产品业务沟通，由产品决定算下单成功还是关闭订单

2、产品决定临界点支付成功，算正常下单成功
【1】更新订单状态(出库中)、扣减库存

<

了解本专栏 订阅专栏 解锁全文 超级会员免费看
JAVA：Spring Boot3 集成 RabbitMQ 死信队列实现支付超时场景
木头
01-13 1838
本文介绍了如何利用RabbitMQ的死信队列实现支付系统订单超时自动撤销功能。通过配置正常队列和死信队列，为订单消息设置TTL（如30分钟），若用户未在规定时间完成支付，消息会转入死信队列触发撤销逻辑。文章详细说明了Java环境下的实现步骤，包括RabbitMQ配置、消息发送和死信队列监听处理。该方案可高效处理超时订单，避免资源浪费，并适用于其他需要超时处理的业务场景。
解决方案：rabbitmq使用场景-超时未支付订单处理
chuanchengdabing的博客
08-30 4614
解决方案：rabbitmq使用场景-超时未支付订单处理 消息的TTL（Time To Live） 消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。 死信交换器 Dead Letter Exchanges 一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。 （1） 一个消息被Consumer拒收了，并且
RabbitMQ订单超时笔记
weixin_67154380的博客
12-22 1467
队列是一种特殊的线性表，特殊之处在于它只允许在表的前端（front)进行删除操作，而在表的后端（rear)进行插入操作，和栈一样，队列是一种操作受限制的线性表。延迟队列，最重要的特性就体现在它的延时属性上，跟普通队列不一样的是，普通队列中的元素总是等着希望被早点取出消费，而延迟队列中的元素则是希望在指定时间被取出消费，所以延迟队列中的元素是都是带时间属性的。利用懒加载的思想，当用户或商户查询订单时，再判断该订单是否超时，超时则进行业务处理。简单来说，延迟队列就是用来存放需要在指定时间被处理的元素的队列。
RabbitMQ实现订单超时案例
SimpleWu
08-26 928
前言 人间清醒 目录前言业务场景JUC(DelayQueue)方案DelayQueue简介JUC DelayQueue实现订单超时案例代码 案例代码Redis Key过期事件方案简介Rabbit Key过期时间实现订单超时案例代码JUC与Redis的不足为什么使用RabbitMQ来实现？RabbitMQ死信队列方案死信队列实现订单超时案例代码延迟消息插件方案延迟消息插件安装延迟消息实现订单超时案...
RabbitMQ消息队列（二）：业务实战订单超时处理
m0_64106946的博客
11-14 1442
本文主要讲解RabbitMq如何处理超时业务，默认您已经对消息队列RabbitMq已经有了基础了解。声明一个延时交换机，一个死信交换机，一个延时队列，一个处理死信队列，并绑定。🤞我是小酥肉 ，喜欢简单 ，期待您的留言👌。我们可以配置队列TTL或者消息TTL。声明一个生产者，一个消费者，并绑定。❤️弱水三千，只取一瓢饮❤️。在控制器注入生产者，发送消息。❤️弱水三千，只取一瓢饮❤️。后，若该订单超过1天没有被。现在有一个需求：订单被。，则手动处理该超时订单。可以看我之前写的博客。
基于RabbitMQ实现订单超时自动处理
qq_68883928的博客
04-23 850
设置消息的存活时间死信队列（DLX）：处理过期消息手动确认机制：确保消息可靠消费订单生产者（投递延迟消息）RabbitMQ配置（队列和交换器）订单消费者（处理超时订单）本文介绍的基于RabbitMQ的订单超时处理方案，相比传统定时任务方式具有明显优势。通过合理利用消息队列的特性，我们构建了一个可靠、高效、实时的订单处理系统。该方案也可扩展应用于其他需要延迟处理的业务场景，如优惠券过期、自动确认收货等。
rabbitmq实现订单下单支付场景
07-28
- *1* *2* [RabbitMQ实现订单超时设计思路、以及在订单过期临界点支付成功如何处理](https://blog.youkuaiyun.com/hkl_Forever/article/details/128216981)[target="_blank" data-report-click={"spm":"1018.2226.3001....
RabbitMQ实战知识详细笔记，消息丢失，重复消费等问题解决方案。
殷志鹏的博客
06-20 1709
RabbitMQ实战知识详细笔记，消息丢失，重复消费等问题解决方案。
【高并发处理的航班查询系统设计要点】：4大策略，从容应对海量请求挑战
高并发系统是现代网络服务不可或缺的组成部分，对服务器扩展、数据库优化、缓存策略以及异步处理技术提出了更高的要求。本文首先介绍了高并发系统的基础知识和架构设计原则，然后探讨了实现高效并发的编程模型、代码...
Java高并发秒杀系统
Teachmepatiently的博客
08-05 1135
每个类都写大量的健壮性判断过于麻烦，我们可以使用 validation 简化我们的代码。比如可以自定义一个@IsMobile注解来判断登录功能中手机号码的合法性。
RabbitMQ订单超时(面试问答)
qq_40946177的博客
11-08 1489
订单系统下单后，MQ会立刻发送一条消息到一个正常的交换机Exchange中，交换机会把消息路由到队列Queue中，我们给这个队列设置一个30分钟的过期时间，当30分钟后，此时消息称为死信队列，将此死信队列绑定一个死信交换机，那么这个死信交换机会把这个消息在路由到它绑定的一个队列queue中，然后用一个库存系统监听一个队列，当订单系统发一条消息之后，过了30分钟库存系统收到这条消息。收到消息后判断订单状态，是否支付，支付了就什么也不做，未支付，取消订单，回滚库存。
阿里面试：生成订单30分钟未支付，则自动取消，该怎么实现？
公众号-老炮说Java
09-11 503
点击上方蓝色字体，选择“标星公众号”优质文章，第一时间送达关注公众号后台回复pay或mall获取实战项目资料+视频来源：blog.youkuaiyun.com/hjm4702192/article/d...
基于RabbitMQ实现的订单超时功能-记录备查
hu10131013的博客
12-14 2831
背景 做过电商系统的人都会遇到一个场景，就是下了订单之后，订单支付会有一个有效期，超时订单自动关闭。实现的技术有很多，再次讨论基于RabbitMQ进行实现 思路 这个是基于RabbitMQ的延迟队列实现的，那需要讨论下什么是延迟队列 延迟队列 延迟队列存储的对象是对应的延迟消息，所谓“延迟消息”是指当消息被发送以后，并不 想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费 。 PS: 在 AMQP 协议中，或者 RabbitMQ 本身没有直接支持延迟队列的功...
【分布式】Rabbitmq死信队列模型、实战场景---订单延迟30min支付处理
a23452的博客
09-18 2281
延时、延迟处理指定的业务逻辑 ---- 在实际生产中非常常见， 比如商城订单完成之后，用户如果一直没有评价，5天后自动好评，会员到期前15天、某个业务到期前X天提示 【 ECS最近给我提示麻了】， 延迟处理的业务逻辑， 之前就是定时器扫表， 但是这样子性能太低了，数据库压力大，RabbitMQ的延迟队列就可以解决
RabbitMQ实现订单30分钟超时自动关闭
我这孩子从小记性就不好，什么东西都要写下来才放心
04-29 5113
订单30分钟未支付,系统自动超时关闭有哪些实现方案? 1.基于任务调度实现,效率是非常低,耗服务器性能 2.基于redis过期key实现.用户下单的时候,生成一个令牌(有效期)30分钟,存放到我们redis; redis.set(orderToken ,orderID) 下单时候存放到redis,并存储id入库,30分钟过期, redis客户端监听,过期获取到orderId,拿orderId去查订单,没有支付则,订单关闭,库存增加 缺点:非常冗余 ,会在表中存放一个冗余字段 3.基于redis延迟队列
RabbitMQ死信队列实战——解决订单超时未支付
weixin_39555954的博客
10-09 6808
一、死信队列 二、产生原因 三、解决订单超时
记录使用rabbit mq处理订单超时业务
weixin_43864927的博客
04-01 2072
记录使用rabbit mq处理订单超时业务 前言：这几天在收尾项目，发现对订单超时的业务做的不够细致(下单15分钟后未付款则订单失效)，我们选择的是最为简单的定时任务来跑缓存中的订单，并筛选出超时的订单进行数据库更新操作，但是这样太消耗服务器的性能了，所以思考是否有别的解决方案 方案当然是有的，就我个人而言，就知道三种方案 就是我们现在所使用的方法，将订单存在redis缓存中，再模糊查询出...
rabbitMQ实现订单超时未支付自动取消订单
晨风若曦的博客
10-21 3103
rabbitMQ实现订单超时未支付自动取消订单
RabbitMQ怎么实现延时支付？
sinat_40693969的博客
03-03 821
RabbitMQ延时支付解决方案
如何使用rabbitmq实现订单超时未支付
最新发布
05-04
<think>好的，用户想用RabbitMQ实现订单超时未支付的功能，使用Java。首先，我需要回忆一下RabbitMQ的相关知识，特别是关于消息过期和死信队列的部分。用户之前的问题提到过订单超时取消，所以可能已经了解了一些基本概念，但需要具体的实现步骤。 首先，订单超时的处理通常有两种方式：定时任务轮询和延迟消息。用户选择了RabbitMQ，所以延迟消息是更合适的方案。RabbitMQ本身不支持直接的延迟队列，但可以通过消息TTL和死信队列来实现。 接下来，我需要考虑如何设置消息的过期时间。消息在队列中超过TTL后会被转发到死信交换机，进而路由到死信队列。这样，消费者监听死信队列就可以处理超时的订单。用户可能需要创建两个队列：一个普通队列设置TTL和死信路由，另一个是死信队列用于处理超时消息。 然后，订单创建时发送消息到普通队列，并设置TTL为订单超时时间，比如30分钟。如果用户支付了订单，需要取消消息，避免不必要的超时处理。这里可能涉及到消息的确认和手动删除，或者使用唯一标识来识别消息。 代码实现部分，需要用Java配置RabbitMQ的相关交换机和队列。声明死信交换机和队列，然后声明业务队列并绑定到死信交换机。发送消息时设置TTL，消费者监听死信队列处理超时订单。 还需要考虑可靠性，比如消息持久化，防止MQ宕机导致消息丢失。发送消息时要确保消息正确到达交换机，可能需要Confirm机制。消费端要处理重复消息，保持幂等性。 用户可能会遇到的问题包括消息重复、顺序问题，以及分布式环境下的系统时间同步。需要提醒用户注意这些点，并提供解决方案，比如数据库状态检查，唯一ID等。 最后，生成相关问题，帮助用户进一步优化和扩展功能，比如如何确保消息不丢失，处理消息积压，或者替代方案如Redis的定时任务。</think>### 通过RabbitMQ实现订单超时未支付检测的Java实现方案 #### 一、实现原理 1. **消息TTL+死信队列**：通过设置消息的存活时间（TTL），当消息过期后会被转发到死信队列（DLX），消费者监听死信队列处理超时订单[^1]。 2. **订单状态校验**：处理超时消息时需检查订单状态，避免重复操作。 #### 二、具体实现步骤 ##### 1. 配置RabbitMQ ```java @Configuration public class RabbitConfig { // 定义业务交换机和队列 @Bean public DirectExchange orderExchange() { return new DirectExchange("order.exchange"); } @Bean public Queue orderQueue() { Map<String, Object> args = new HashMap<>(); args.put("x-dead-letter-exchange", "dlx.exchange"); // 绑定死信交换机 args.put("x-dead-letter-routing-key", "dlx.key"); // 死信路由键 return new Queue("order.queue", true, false, false, args); } @Bean public Binding orderBinding() { return BindingBuilder.bind(orderQueue()).to(orderExchange()).with("order.key"); } // 定义死信交换机和队列 @Bean public DirectExchange dlxExchange() { return new DirectExchange("dlx.exchange"); } @Bean public Queue dlxQueue() { return new Queue("dlx.queue"); } @Bean public Binding dlxBinding() { return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with("dlx.key"); } } ``` ##### 2. 发送延迟消息 ```java @Service public class OrderService { @Autowired private RabbitTemplate rabbitTemplate; public void createOrder(Order order) { // 保存订单到数据库（状态为待支付） order.setStatus(0); orderMapper.insert(order); // 发送延迟消息（设置30分钟超时） MessageProperties props = new MessageProperties(); props.setExpiration("1800000"); // TTL单位毫秒 Message message = new Message(order.getOrderId().getBytes(), props); rabbitTemplate.convertAndSend("order.exchange", "order.key", message); } } ``` ##### 3. 消费超时消息 ```java @Component @RabbitListener(queues = "dlx.queue") public class OrderTimeoutConsumer { @Autowired private OrderService orderService; @RabbitHandler public void process(String orderId) { Order order = orderService.getOrder(orderId); if (order != null && order.getStatus() == 0) { orderService.cancelOrder(orderId); // 执行取消订单逻辑 } } } ``` #### 三、关键优化点 1. **消息可靠性**： - 启用生产者确认模式（publisher confirms） - 消息持久化（队列和消息都设置为持久化） 2. **幂等性处理**： ```java // 在取消订单方法中增加状态校验 public void cancelOrder(String orderId) { Order order = orderMapper.selectById(orderId); if (order.getStatus() == 0) { order.setStatus(2); // 修改为已取消 orderMapper.updateById(order); } } ``` 3. **支付成功删除消息**： ```java public void paySuccess(String orderId) { // 支付成功时删除对应的延迟消息 rabbitTemplate.execute(channel -> { channel.queuePurge("order.queue"); // 实际应通过messageId精准删除 return null; }); } ``` #### 四、注意事项 1. **消息时效误差**：RabbitMQ的TTL检查是周期性执行的（默认1分钟一次），可能存在最多59秒延迟 2. **分布式系统时间**：建议使用服务器统一时间，避免本地时间差异 3. **消息顺序问题**：队列采用FIFO特性，但不同订单的TTL设置需保持一致
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值