RabbitMQ结构
- 左侧 P 代表 生产者，也就是往 RabbitMQ 发消息的程序。
- 中间即是 RabbitMQ，其中包括了 交换机 和 队列。
- 右侧 C 代表 消费者，也就是往 RabbitMQ 拿消息的程序。
一般的队列服务：发消息，队列，收消息，RabbitMQ在生产者和队列之间加入了交换机（Exchange），这样解耦了生产者与队列之间的联系，转变为由交换机把消息根据调度策略把消息给队列。
为什么要使用MQ？
- 异步处理
比如注册，用户注册完成后需要发短信，在这里短信不是必须的，它只是一个通知。 -
流量削峰
秒杀系统，用户请求写入消息队列，设置队列最大长度，如果超过，则直接丢弃也就是用户直接进入错误页面。
image.png - 服务解耦
假设服务A产生数据, 而服务B,C,D需要这些数据, 那么我们就需要在A服务中直接调用B,C,D服务,把数据传递到下游服务。如果服务越来越多，再考虑到下游服务出错的情况，处理将会越来越复杂。可以转变为A发布消息，B,C,D依照自己的需要订阅或者不订阅。
如果确保消息正确发送到RabbitMQ，如何确保消息接收方消费了消息？
消息发送确认
- publisher-confirms模式，该模式关系消息有没有传递到Exchange，不关心从Exchange到没到queue
- publisher-returns模式，该模式会在消息没有被路由到queues时将消息返回
消息消费确认
RabbitMQ默认是自动确认，自动被确认消费会从MQ中删除可以。
可以设置为手动确认，那么成功后channel.basicAck(long deliveryTag, boolean multiple);失败后需要channel.basicNack(long deliveryTag, boolean multiple, boolean requeue);
消息基于什么传输？
由于TCP连接的创建和销毁开销很大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据，信道（channel）是建立在真实TCP基础上的虚拟连接，且每条TCP上的通道数量没有限制。
如何避免消息重复投递和重复消费？
在消息生产时，MQ内部针对每条消息生成一个inner-msg-id，作为去重的依据。
在消息消费时，要求消息体中必须要有一个bizId作为去重的依据，避免同一条消息被重复消费。
如何确保消息不丢失？
消息持久化，前提是队列持久化
RabbitMQ宕机重启恢复方式是，写入磁盘上的持久化日志文件。
消息怎么路由？
消息提供方-->路由-->一至多个队列
消息发布到交换器时，消息将拥有一个路由键；
通过队列路由键，可以把队列绑定到交换器上；
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配。
常见的交换器有三种：
fanout：如果交换器收到消息，将会广播到所以绑定的队列
direct：如果路由键完全匹配，消息被投递到相应的队列
topic：可以是来自不同源头的消息能够到达同一队列，使用topic交换器时，可以使用通配符。
