一、workqueues
多个消费者监听同一个队列，提高处理速度
相比简单模式多加了消费者，类似于分布式，加快了处理消息的速度
实际项目只声明一次队列，一般声明在消费者，因为消费者是一直运行的，不能关闭资源
代码加一个消费者，就是复制一份消费者类即可，偶数就平均分配，奇数就一边2个一边3个
二、publish/subscribe发布订阅（又叫扇出模式）
将一个交换机里面的消息给多个队列，（消息同时发送到邮件队列和短信队列，两个消费者，一个监听邮件，一个监听短信（sms：short messaging service)
类似于建两个最简单的场景，只不过要发两遍消息，而上面的只需要发一次消息
2.1 交换机
不同于简单模式，发布订阅要自定义交换机，类似于定义队列我们也定义在消费者；不写路由，路由为""
交换机有两个参数，一个是名字，一个是交换机的类型，发布订阅模式就是FANOUT（扇出，用的枚举）
2.2 绑定交换机和生产者
因为没有路由，把交换机和队列绑上即可，它会把消息发送到所有队列，没有路由还是惯例写""
三、Routing(路由模式)
队列和交换机绑定在一起，消息根据路由发送到指定队列
3.1 交换机和队列绑定路由
四、Topic（通配，以后都用这种）
解决有些消息既要进消息队列，又要进短信队列
定义路由的通配规则
这种两个队列都会进
五、消息属性
生产者，注意这里的过期时间是字符串
消费者都取得到
六、消息确认机制
为保证消息在发送和处理时消息不丢失
生产者发送消息，有确认机制
消费者处理消费，有确认机制
6.1 生产端确认机制
6.1.1 生产者确认
监听要开一个线程
注意：要监听确认发送了消息，连接不能关闭
6.1.2 return机制
如果路由不到，返回监听信息，也是消息传递失败
没发到信息，要在handleReturn里面进行记日志，记录数据库或人工干预等等
6.2 消费端确认机制（ACK和限流）
消费者确认机制：自动确认，手动确认
自动：
手动：
6.2.1 消费者确认
限流一般和ack一起用：
限流一般一次一个，多个消费者谁快谁处理的消息多
自动确认改为false
最后要执行.basicAck才算处理信息结束，否则消息还会给你退回来，保证消息不丢
6.2.2 NACK重回队列
消费者处理失败NACK
try{
ack();
}catch(){
//处理失败，nack()
可以重回队列
可以不重回队列
消息丢失
有死信队列进入死信队列，没有死信队列消息丢失
nack();
}
消息直接丢失可以解决，进入死信队列，下面详讲
还有一种处理办法，就是消息拒绝，拒绝后消息也会丢失，让处理失败的信息不丢失，解决方法也是死信队列
少了个批量处理的参数，默认一次处理一个
七、队列属性
所有消息的过期时间不是字符串，为数字类型
八、死信队列
RabbitMQ其实应该叫死信交换机，沿用其他消息队列的概念
8.1 什么是死信
满足以下条件的消息，都会进入死信队列
8.2 死信测试
8.2.1 先搭建一个接受消息的交换机和队列
8.2.2 搭建死信交换机和死信队列
8.2.3 绑定死信交换机和队列
其实就是设置普通队列的两个属性
8.2.4 再建一个消费者来专门处理死信队列
略
九、死信队列实现延迟队列
处理秒杀经典案例：下的订单都放到订单队列，设定过期时间，没有消费者处理它，等到过期时间全部进入死信队列，然后处理死信队列，处理过的消息再进行redis内订单操作