java支付订单超时设置_基于rabbitMQ 消息延时队列方案 模拟电商超时未支付订单处理场景...

前言

传统处理超时订单

采取定时任务轮训数据库订单，并且批量处理。其弊端也是显而易见的；对服务器、数据库性会有很大的要求，并且当处理大量订单起来会很力不从心,而且实时性也不是特别好

当然传统的手法还可以再优化一下，即存入订单的时候就算出订单的过期时间插入数据库，设置定时任务查询数据库的时候就只需要查询过期了的订单，然后再做其他的业务操作

jdk延迟队列 DelayQueue

采取jdk自带的延迟队列能很好的优化传统的处理方案，但是该方案的弊、端也是非常致命的，所有的消息数据都是存于内存之中，一旦宕机或重启服务队列中数据就全无了，而且也无法进行扩展。

rabbitMQ延时队列方案 rabbitmq我就不多介绍了，一台普通的rabbitmq服务器单队列容纳千万级别的消息还是没什么压力的，而且rabbitmq集群扩展支持的也是非常好的，并且队列中的消息是可以进行持久化，即使我们重启或者宕机也能保证数据不丢失

存活时间(Time-To-Live 简称 TTL),分别有三种TTL的设置模式

x-message-ttl ,该属性是在创建队列的时候 ，在arguments的map中配置；该参数的作用是设置当前队列中所有的消息的存活时间

x-expires 该属性也是在arguments中配置；其作用是设置当前队列在N毫秒中(不能为0,且为正整数)，就删除该队列；“未使用”意味着队列没有消费者，队列尚未重新声明，并且至少在有效期内未调用basicGet (basicGet 是手动拉取指定队列中的一条消息)

AMQP.BasicProperties配置中的exppiration 属性，前两者都是基于队列的TTL，该属性是基于单条消息的TLL用于配置每条消息在队列中的存活时间

死信交换(Dead Letter Exchanges 简称 DLX)

”死信交换“ 可以分开来理解 ；首先是 ”死信“，也就是死亡的信息，无效的信息；造成这样的信息有以下几种情况 消息被拒绝，即消费者没有成功确认消息被消费 消息TTL过期 超出队列长度限制 当出现这三种情况的时候，队列中的消息就会变为“死信”

再来理解”交换“ 也就是说，当出现"死信"的情况下 rabbitmq 可以对该"死信"进行交换到别的队列上，但是交换的前提是需要为死信配置一个交换机用于死信的交换

代码实现

配置类 RabbitmqConfiguration

import com.rabbitmq.client.Connection;

import com.rabbitmq.client.ConnectionFactory;

/**

* TODO rabbitmq配置类

*/

public class RabbitmqConfiguration {

private final String SERVER_HOST="127.0.0