概念：
消息超时
这个很简单，队列中的消息，不设置超时时间并且消费者宕机，就会越放越多，所以我们可以在创建queue的时候设置一个队列大小和队列超时时间。
死信交换机和死信队列：
专门收集一些拒绝接受的，超时未消费的，超出了队列大小的消息任务。
使用场景：
（1）10件商品，100个用户进来购买，队列中大小设置为10，只允许10用户购买请求进来，其他的都reject，reject的这部分都会自动进行死信队列中，这也可以换成超出队列大小的情况。
（2）10件商品，100个用户进来购买，全部购买请求都放过期时间为10分钟的队列中，付款完成后算消费成功，10分钟不付款的订单记录自动消失。超时消失的这部分消息自动进入到死信队列中记录。
当然还有更多更复杂的，就靠自己DIY～
当然直接入库或者通过redis也可以做，都可以，我当时设计抢购的模块是这样选择的：
通过MQ设置队列大小限制抢购数量和保存购买的用户请求，这样既可以保证有序，又可以保证超买超卖，Redis保存预扣商品库存的数量，支付时通过MQ的用户购买请求和Redis中的预扣库存生成订单，调起支付的API和JS，完成支付后，扣除商品实际库存数量和消费掉MQ中该用户的购买请求。如果他一直没能支付成功，MQ中的购买请求超时失效，订单会保留，但是修改状态为支付超时即可。
同时，如果MQ占满情况下，没有死信队列，会直接丢弃购买信息。有了死信队列，可以在前面有用户支付超时或者退款的情况下移除该用户出MQ，此时购买MQ的大小变为未满，这时批量提醒死信队列中的用户，告诉他们现在“有机会”，让他们进行二轮抢购。
这就是我的使用场景和解决方案，有的大神说：这么麻烦干嘛？我直接一个滑铲，哦不，一个数据库的增删改查也可以。当然也可以，怎么选择是自己的事情。
整体流程
demo：
（1）先创建一个正常业务的交换机：
（2）在创建一个专门用于接受和转发死信规则的死信交换机
要创建时候Argument参数加上x-dead-letter-exchange = 自己定义的死信交换机名称即可
（3）创建一个dead.letter作为正常业务队列，设置过期时间和设置最大限制，这样才能让消息在这个正常业务队列过期。这个正常业务的可以不加x-dead-letter-exchange也行
创建成功！
（4）创建一个dlx.queue作为全局死信队列，跟刚才创建做法一样，不需要过期时间和最大限制也行，反正它就是一个垃圾桶的作用
（5）将正常业务队列与正常业务交换机和死信交换机都要绑定！
（6）死信队列只需要绑定死信交换机
（7）正常业务交换机要绑定正常业务队列（废话）我这里命名不规范，有歧义，反正记得dead.letter就是正常业务队列哈～
（8）死信交换机绑定正常业务队列和死信队列
（9）测试：首先发送一条消息去dead.letter队列，没有任何消费者，过期时间十秒，看它会不会自己转发到死信队列
清晰看到目前正常业务队列收到了消息，死信队列中有3条死信。此时dead.letter无消费，过期时间10秒，等待10秒～
