RabbitMQ 知识总结

一、为什么使用 MQ?

好的架构不是设计出来的，是演进出来的，使用 MQ 必定有其道理，是用来解决实际问题的。其实使用 MQ 的场景挺多的，但是比较核心的有 3 个：异步、解耦、削峰填谷。

二、MQ 优缺点

1、系统可用性降低
大家想象一下，上面的说解耦的场景，本来 A 系统的哥们要把系统关键数据发送给 BC 系统的，现在突然加入了一个 MQ 了，现在 BC 系统接收数据要通过 MQ 来接收。但是大家有没有考虑过一个问题，万一 MQ 挂了怎么办?这就引出一个问题，加入了 MQ 之后，系统的可用性是不是就降低了?因为多了一个风险因素：MQ 可能会挂掉。只要 MQ 挂了，数据没了，系统运行就不对了。

2、系统复杂度提高
本来我的系统通过接口调用一下就能完事的，但是加入一个 MQ 之后，需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题。为了解决这些问题，又需要引入很多复杂的机制，这样一来是不是系统的复杂度提高了。

3、数据一致性问题
本来好好的，A 系统调用 BC 系统接口，如果 BC 系统出错了，会抛出异常，返回给 A 系统让 A 系统知道，这样的话就可以做回滚操作了。但是使用了 MQ 之后，A 系统发送完消息就完事了，认为成功了。而刚好 C 系统写数据库的时候失败了，但是 A 认为 C 已经成功了?这样一来数据就不一致了。通过分析引入 MQ 的优缺点之后，就明白了使用 MQ 有很多优点，但是会发现它带来的缺点又会需要你做各种额外的系统设计来弥补。最后你可能会发现整个系统复杂了好几倍，所以设计系统的时候要基于这些考虑做出取舍，很多时候你会发现该用的还是要用的。

三、如何保证 MQ 消息不丢失

1、生产者弄丢了数据
RabbitMQ 生产者将数据发送到 RabbitMQ 的时候，可能数据在网络传输中搞丢了，这个时候 RabbitMQ 收不到消息，消息就丢了。RabbitMQ 提供了两种方式来解决这个问题：事务方式：在生产者发送消息之前，通过channel.txSelect开启一个事务，接着发送消息。如果消息没有成功被 RabbitMQ 接收到，生产者会收到异常，此时就可以进行事务回滚channel.txRollback，然后重新发送。假如 RabbitMQ 收到了这个消息，就可以提交事务channel.txCommit。但是这样一来，生产者的吞吐量和性能都会降低很多，现在一般不这么干。另外一种方式就是通过 Confirm 机制：这个 Confirm 模式是在生产者那里设置的，就是每次写消息的时候会分配一个唯一的 ID，然后 RabbitMQ 收到之后会回传一个 ACK，告诉生产者这个消息 OK 了。如果 RabbitMQ 没有处理到这个消息，那么就回调一个 Nack 的接口，这个时候生产者就可以重发。事务机制和 Confirm 机制最大的不同在于事务机制是同步的，提交一个事务之后会阻塞在那儿。但是 Confirm 机制是异步的，发送一个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。所以一般在生产者这块避免数据丢失，都是用 Confirm 机制的。

2、RabbitMQ 弄丢了数据
RabbitMQ 集群也会弄丢消息，这个问题在官方文档的教程中也提到过，就是说在消息发送到 RabbitMQ 之后，默认是没有落地磁盘的，万一 RabbitMQ 宕机了，这个时候消息就丢失了。所以为了解决这个问题，RabbitMQ 提供了一个持久化的机制，消息写入之后会持久化到磁盘。这样哪怕是宕机了，恢复之后也会自动恢复之前存储的数据，这样的机制可以确保消息不会丢失。设置持久化有两个步骤：

第一个是创建 Queue 的时候将其设置为持久化的，这样就可以保证 RabbitMQ 持久化 Queue 的元数据，但是不会持久化 Queue 里的数据。
第二个是发送消息的时候将消息的 deliveryMode 设置为 2，就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
但是这样一来可能会有人说：万一消息发送到 RabbitMQ 之后，还没来得及持久化到磁盘就挂掉了，数据也丢失了，怎么办?对于这个问题，其实是配合上面的 Confirm 机制一起来保证的，就是在消息持久化到磁盘之后才会给生产者发送 ACK 消息。万一真的遇到了那种极端的情况，生产者是可以感知到的，此时生产者可以通过重试发送消息给别的 RabbitMQ 节点。

3、消费端弄丢了数据
RabbitMQ 消费端弄丢了数据的情况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候 RabbitMQ 就会认为你已经消费成功了，这条数据就丢了。对于这个问题，要先说明一下 RabbitMQ 消费消息的机制：在消费者收到消息的时候，会发送一个 ACK 给 RabbitMQ，告诉 RabbitMQ 这条消息被消费到了，这样 RabbitMQ 就会把消息删除。但是默认情况下这个发送 ACK 的操作是自动提交的，也就是说消费者一收到这个消息就会自动返回 ACK 给 RabbitMQ，所以会出现丢消息的问题。所以针对这个问题的解决方案就是：关闭 RabbitMQ 消费者的自动提交 ACK，在消费者处理完这条消息之后再手动提交 ACK。这样即使遇到了上面的情况，RabbitMQ 也不会把这条消息删除，会在你程序重启之后，重新下发这条消息过来。