本文共 907 字，大约阅读时间需要 3 分钟。
1. 使用场景
在实际项目中，消息中间件的延迟推送功能被广泛应用于多个场景。例如，淘宝的七天自动确认收货机制中，系统在签收商品后会启动一个七天的延迟通知过程。物流系统会在这七天后向支付系统发送消息，通知款项打款给商家。这一过程充分利用了消息中间件的延迟推送能力。
另一个典型应用场景是12306购票系统的支付确认页面。用户在选票后点击确定跳转到确认页面，页面通常会显示倒计时提示，30分钟内未完成订单将自动取消。为了实现这一功能，购票业务系统会在订单生成的初始时刻向订单系统发送一个延迟消息，通知系统在30分钟内完成订单处理。如果用户在30分钟内完成了订单，系统会通过逻辑判断忽略掉收到的延迟消息。
尽管如此，我们在实际项目中使用传统的解决方案往往面临着严重的性能问题。
2. 传统解决方案的不足
传统解决方案主要包括以下三种方式：
使用Redis设置订单过期时间。这种方法通过在Redis中存储订单信息并设置过期时间，最后判断Redis中是否存在该订单来决定订单状态。然而，这种方法在面对恶意刷单或大规模恶意下单时，会对Redis的内存造成巨大压力，严重影响系统性能。
使用传统数据库轮询。这种方式通过频繁查询数据库表中的订单状态来判断订单状态，导致大量IO操作，系统吞吐量极低，难以应对高并发场景。
使用JVM原生的DelayQueue。这种方法虽然能够实现延迟队列功能，但其内存占用较高且缺乏持久化策略，系统在宕机或重启时会丢失订单信息，存在数据不可恢复的问题。
这些传统解决方案在处理高并发场景时都存在明显性能瓶颈，难以满足系统的高效运行需求。
3. RabbitMQ的延迟队列实现
在RabbitMQ 3.6.x版本之前，常用的延迟队列实现方式是结合死信队列和TTL过期时间。这种方法虽然能实现延迟推送，但在高并发场景下容易遇到消息堆积和系统性能下降的问题。
随着RabbitMQ 3.6.x版本的推出，RabbitMQ官方开始提供延迟队列插件——rabbitmq-delayed-message-exchange。这一插件提供了更加高效和灵活的延迟消息处理方式，有效解决了传统延迟队列实现中的性能问题。
发表评论
最新留言
关于作者
