队列的工作模式
- work queues 工作序列模式
生产者发送一个消息，多个消费者来消费队列里的消息；
consumer端的autoAck字段设置的是false，这表示consumer在接收消息后不会自动反馈服务已经消费了message，而在对message处理完成了之后，再调用channel.basicAck来通知服务器已经消费了该message。
2.Publish/Subscribe 订阅 发布机制
type为fanout的 exchange
可以把Producer与Consumer进行进一步的解耦。消息进入哪个queue，由exchange来分配。
3.Routing基于内容的路由
type为direct的exchange
4.Topics基于话题的路由
type为topic的exchange
队列详解
1.Classic经典队列
Durability有两个选项，Durable和Transient，前者表示队列会将消息保存到硬盘，这样消息的安全性更高。担心性能会低；
2.Quorum仲裁队列
在分布式环境下对消息的可靠性保障更高。
基于Raft一致性协议实现的一种新型的分布式消息队列，他实现了持久化，多备份的FIFO队列。简单理解就是quorum队列中的消息需要有集群中多半节点同意确认后，才会写入到队列中。保证消息在分布式环境中的高可靠。
3.Stream流式队列
大规模分发
当想要向多个订阅者发送相同消息时，以往的队列类型必须为每个消费者绑定一个专用的队列。数据量大导致性能下降，stream可以允许任意的消费者使用同一个队列的消息。
stream队列允许用户在日志的任何一个链接点开始重新读取数据
对信息传递吞吐量的提升非常明显。
可以比较轻松的在队列中积累百万级的消息。
死信队列
是RabbitMQ中对于未能正常消费的消息进行一种补救机制。死信队列也是一种普通的队列。同样可以在队列上声明消费者，继续对消息进行消费处理。
产生死信队列的原因
1.消息被消费者确认拒绝。消费者把requeue参数设置为true，并且在消费后，向RabbitMQ返回拒绝。
2.消息达到预设的TTL时限还一直没有被消费
3.消息由于队列已经达到最大长度限制而被丢弃。
懒队列
会尽可能早的将消息内容保持到硬盘中，并且只有在用户请求的时候，才临时从硬盘加载到RAM内存中。
为了支持非常长的队列，可以理解为平常的队列堆积。
RabbitMQ服务高可用
一：RabbitMQ如何保证消息不丢失？
1.哪些环境会可能丢失消息
生产者
生产者保证消息正确发送到RibbitMQ；有同步或者异步确认机制，设置指定完成的时间。
消费者
消费者会在完成业
务处理后自动进行应答，而如果消费者的业务逻辑抛出异常，RabbitMQ会将消息进行重试，这样是不会丢
失消息的，但是有可能会造成消息一直重复消费。
磁盘
再Rabbitmq中，对于Classics经典队列。直接将队列声明为持久化队列即可。 保证服务端不会丢失
二：如何保证消息幂等？
当消费者消费消息处理业务逻辑时，如果抛出异常，或者不向RabbitMQ返回响应，默认情况下，
RabbitMQ会无限次数的重复进行消息消费。
设计一个全局的messageId，根据这个做幂等处理。
业务代码也做唯一处理。
三：如何保证消息的顺序？
唯一比较好的策略就是 单队列+单消息推送。但是会消耗性能。
四：关于RabbitMQ的数据堆积问题如何处理？
要提升消费速度最直接的方式，就是增加消费者数量了。尤其当消费端的服务出现问题，已经有大量消息
堆积时。这时，可以尽量多的申请机器，部署消费端应用，争取在最短的时间内消费掉积压的消息。但是这
种方式需要注意对其他组件的性能压力。
