自己对RabbitMQ的理解

最基本的几种模式

MQ的特点

削锋：减少高峰时期对服务器的压力
异步：对于不是特别重要的一些请求。假如说有一个操作，要调用三个服务，A服务200ms，B服务300ms，C服务200ms，如果不使用mq的话，用户至少要等700ms，使用mq的话，直接发送3条消息到mq里，大大减少了耗时时间，同时用户体验也上个档次

解耦：一个系统调用多个模块。互相调用的关系很复杂很麻烦。如果没有消息队列，每当一个新业务接入，我们都要在主系统调用新接口。使用消息队列，我们只需要关心是否送达。服务自己订阅想要的信息即可

消息基于什么传输?

由于 TCP 连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的 TCP 连接内的虚拟连接，且每条 TCP 连接上的信道数量没有限制。

消息确认机制和消息重发机制

如何防止消息丢失

首先消息丢失可能出现在生产者，mq和消费者中。我们分情况讨论

生产者丢失

首先来说一下生产者丢失，生产者丢失就是数据发送到mq 的时候，可能数据在半路就丢失了，比如网络问题。这个时候有2中解决方案。第一种是使用rabbitmq提供的事务功能，就是生产者发送数据之前开启事务channel.txselect。这样如果消息没有被mq接到，生产者就会异常报错，此时可以回滚事务channel.txrollback，然后重发消息。如果成功收到了消息，可以提交事务channel.txcommit 但这样太耗性能并且吞吐量相对来说比较低。第二种是可以使用confirm模式，每次都会分配一个唯一id，如果成功写入mq，返回一个ack信息，如果没有西入禁区，回调一个nack接口、事务和confirm机制的最大不同在于事务是同步的，会阻塞在那里，但confirm是异步的。所以我们一般使用confirm

Mq丢失

Mq本身丢失了数据。我们可以使用持久化解决这个问题。也就是将消息写入磁盘。这样就算挂了，恢复之后也会自动读取之前持久化的数据首先我们开启队列持久化，创建队列的时候设置为true，然后将消息的deliveryMode设置为2 这个是消息持久化。这两个设置下来后，哪怕mq宕机了，重启之后，也会从磁盘上恢复队列，恢复队列的数据

消费者丢失

假如说，我们消费某一条消息的时候，消费到一半，mq宕机了，或者mq重启了。这条消息不就没了。我们怎么处理呢我们可以使用mq提供的ack机制，设置为手动签收。这样的话，每次处理完之后，我们用代码手动的签收一下就可以了。