死信队列ttlttl（生存时间），消息生存时间RabbitMQ支持两种ttl设置：整个队列配置ttl，所有投递到队列的消息都在mostNindividualmessageswillnotsurvivetoconfigurettl如果队列的TTL和消息的TTL都配置了，会使用较小的值。死信消息死信发生在以下3种情况：消费者拒绝消息（basic.reject/basic.nack），不重新入队requeue=false消息未在队列中消费，超出队列或消息本身当过期TTL（time-to-live）队列的消息长度达到限制，出现死信时，该队列绑定一个死信开关，死信消息会被路由到死信队列中deadletterswitchDLXdeadletterswitch和deadletter队列的声明与普通的交换机和队列没有区别，只是在普通队列的声明中指定了如下属性：Mapargs=newHashMap<>(3);//消息过期后，进入死信交换args.put("x-dead-letter-exchange","指定死信交换名称");消息进入死信队列后，我们仍然可以在监听器上做一些特殊的处理。例如：订单十分钟内未付款，则自动取消。我们可以设置队列的ttl为10分钟，将需要支付的订单id作为消息放入其中；同时绑定死信队列，然后消费者监听死信队列。这样，当消息超时后，消息就会进入死信队列，被消费者获取；消费者只需要完成订单取消逻辑即可。查看延迟队列的ttl。如果设置了队列的ttl属性，一旦消息过期，就会被队列丢弃；消息级别的ttl有点神秘。例如，一条消息的ttl很短，而前一条消息的ttl却很长——这种情况下，即使消息过期，也不会立即丢弃。也就是说，消息层面的超时时间会受到队列中消息堆积的影响。那么如果延迟不固定，通过死信队列实现就会有问题。比如这个要求：会议室预订成功后，会议开始前10分钟。使用在队列上设置ttl的方法，由于时间不固定，难免队列太多。使用在消息上设置ttl的方法，会因为消息堆积导致通知不准确甚至无法通知。如何解决这个问题呢？只需安装rabbitmq_delayed_message_exchange插件。生产者关键代码：Mapargs=newHashMap();args.put("x-delayed-type","direct");channel.exchangeDeclare(exchangename,"x-delayed-message",true,false,args);附录P6-P7知识集
