大家平时也有用到一些消息中间件(MQ)，但是对其理解可能仅停留在会使用 API 能实现生产消息、消费消息就完事了。
图片来自pexels
对 MQ 更加深入的问题，可能很多人没怎么思考过。比如，你跳槽面试时，如果面试官看到你简历上写了熟练掌握消息中间件。
那么很可能给你发起如下 4 个面试连环炮：
- 为什么要使用 MQ?
- 使用了 MQ 之后有什么优缺点?
- 怎么保证 MQ 消息不丢失?
- 怎么保证 MQ 的高可用性?
本文将通过一些场景，配合着通俗易懂的语言和多张手绘彩图，讨论一下这些问题。
为什么要使用 MQ?
相信大家也听过这样的一句话：好的架构不是设计出来的，是演进出来的。
这句话在引入 MQ 的场景同样适用，使用 MQ 必定有其道理，是用来解决实际问题的。而不是看见别人用了，我也用着玩儿一下。
其实使用 MQ 的场景挺多的，但是比较核心的有 3 个：
- 异步
- 解耦
- 削峰填谷
异步
我们通过实际案例说明：假设 A 系统接收一个请求，需要在自己本地写库执行 SQL，然后需要调用 BCD 三个系统的接口。
假设自己本地写库要 3ms，调用 BCD 三个系统分别要 300ms、450ms、200ms。
那么最终请求总延时是 3+300+450+200=953ms，接近 1s，可能用户会感觉太慢了。
此时整个系统大概是这样的：
但是一旦使用了 MQ 之后，系统 A 只需要发送 3 条消息到 MQ 中的 3 个消息队列，然后就返回给用户了。
假设发送消息到 MQ 中耗时 20ms，那么用户感知到这个接口的耗时仅仅是 20+3=23ms，用户几乎无感知，倍儿爽!
此时整个系统结构大概是这样的：
可以看到，通过 MQ 的异步功能，可以大大提高接口的性能。
解耦
假设 A 系统在用户发生某个操作的时候，需要把用户提交的数据同时推送到 B、C 两个系统的时候。
这个时候负责 A 系统的哥们想：没事啊，B、C 两个系统给我提供一个 HTTP 接口或者 RPC 接口，我把数据推送过去不就完事了嘛。负责 A 系统的哥们美滋滋。
如下图所示：
一切看起来很美好，但是随着业务快速迭代，这个时候系统 D 也想要这个数据。那既然这样，A 系统的开发同学就改咯，在发送数据给 BC 的同时加上一个 D。
但是，越到后面越发现，麻烦来了。整个系统好像不止这个数据要发送给 BCD、还有第二、第三个数据要发送给 BCD。甚至有时候又加入了 E、F 等系统，他们也要这个数据。
并且有时候可能 B 系统突然又不要这个数据了，A 系统改来改去，A 系统的开发哥们头皮发麻。
更复杂的场景是，数据通过接口传给其他系统有时候还要考虑重试、超时等一些异常情况，真是头发都白了呀。
来看下图，体会一下这无助的现场：
这个时候，就该我们的 MQ 粉墨登场了!这种情况下使用 MQ 来解耦是再合适不过了，因为负责 A 系统的哥们只需要把消息扔到 MQ 就行了，其他系统按需来订阅消息就好了。
就算某个系统不需要这个数据了，也不会需要 A 系统改动代码。看看加入 MQ 解耦的下图，是不是清爽了很多：
削峰填谷
举个例子，比如我们的订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒 1000 左右的并发写入，并发量再高就容易宕机。
低峰期的时候并发也就 100 多个，但是在高峰期时候，并发量会突然激增到 5000 以上，这个时候数据库肯定死了。
如下图，来感受一下数据库被打死的绝望：
但是使用了 MQ 之后，情况就变了!消息被 MQ 保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒 1000 个数据，这样慢慢写入数据库，这样就不会打死数据库了。
整个过程，如下图所示：
至于为什么叫做削峰填谷呢?来看看这个图：
如果没有用 MQ 的情况下，并发量高峰期的时候是有一个“顶峰”的，然后高峰期过后又是一个低并发的“谷”。
但是使用了 MQ 之后，限制消费消息的速度为 1000QPS，但是这样一来，高峰期产生的数据势必会被积压在 MQ 中，高峰就被“削”掉了。
但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在 1000QPS，直到消费完积压的消息，这就叫做“填谷”。
通过上面的分析，大家就可以知道为什么要使用 MQ，以及使用了 MQ 有什么好处。知其所以然，明白了自己的系统为什么要使用 MQ。
这样以后别人问你为啥要用 MQ，就不会出现 “我们组长要用 MQ 我们就用了” 这样尴尬的回答了。
使用了 MQ 之后有什么优缺点?
看到这个问题蒙圈了，用了就用了嘛!优点上面已经说了，但是这个缺点是啥啊。好像没啥缺点啊。
如果你这样想，就大错特错了，在设计系统的过程中，除了要清楚的知道为什么要用这个东西，还要思考一下用了之后有什么坏处。这样才能心里有底，防范于未然。
接下来我们就讨论一下，用 MQ 会有什么缺点吧?
系统可用性降低
大家想象一下，上面的说解耦的场景，本来 A 系统的哥们要把系统关键数据发送给 BC 系统的，现在突然加入了一个 MQ 了，现在 BC 系统接收数据要通过 MQ 来接收。
但是大家有没有考虑过一个问题，万一 MQ 挂了怎么办?这就引出一个问题，加入了 MQ 之后，系统的可用性是不是就降低了?
因为多了一个风险因素：MQ 可能会挂掉。只要 MQ 挂了，数据没了，系统运行就不对了。
系统复杂度提高
本来我的系统通过接口调用一下就能完事的，但是加入一个 MQ 之后，需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题。
为了解决这些问题，又需要引入很多复杂的机制，这样一来是不是系统的复杂度提高了。
数据一致性问题
本来好好的，A 系统调用 BC 系统接口，如果 BC 系统出错了，会抛出异常，返回给 A 系统让 A 系统知道，这样的话就可以做回滚操作了。
但是使用了 MQ 之后，A 系统发送完消息就完事了，认为成功了。而刚好 C 系统写数据库的时候失败了，但是 A 认为 C 已经成功了?这样一来数据就不一致了。
通过分析引入 MQ 的优缺点之后，就明白了使用 MQ 有很多优点，但是会发现它带来的缺点又会需要你做各种额外的系统设计来弥补。
***你可能会发现整个系统复杂了好几倍，所以设计系统的时候要基于这些考虑做出取舍，很多时候你会发现该用的还是要用的。
怎么保证 MQ 消息不丢失?
使用了 MQ 之后，还要关心消息丢失的问题。这里我们挑 RabbitMQ 来说明一下吧。
生产者弄丢了数据
RabbitMQ 生产者将数据发送到 RabbitMQ 的时候，可能数据在网络传输中搞丢了，这个时候 RabbitMQ 收不到消息，消息就丢了。
RabbitMQ 提供了两种方式来解决这个问题：
事务方式：在生产者发送消息之前，通过`channel.txSelect`开启一个事务，接着发送消息。
如果消息没有成功被 RabbitMQ 接收到，生产者会收到异常，此时就可以进行事务回滚`channel.txRollback`，然后重新发送。假如 RabbitMQ 收到了这个消息，就可以提交事务`channel.txCommit`。
但是这样一来，生产者的吞吐量和性能都会降低很多，现在一般不这么干。
另外一种方式就是通过 Confirm 机制：这个 Confirm 模式是在生产者那里设置的，就是每次写消息的时候会分配一个唯一的 ID，然后 RabbitMQ 收到之后会回传一个 ACK，告诉生产者这个消息 OK 了。
如果 RabbitMQ 没有处理到这个消息，那么就回调一个 Nack 的接口，这个时候生产者就可以重发。
事务机制和 Confirm 机制***的不同在于事务机制是同步的，提交一个事务之后会阻塞在那儿。
但是 Confirm 机制是异步的，发送一个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。
所以一般在生产者这块避免数据丢失，都是用 Confirm 机制的。
RabbitMQ 弄丢了数据
RabbitMQ 集群也会弄丢消息，这个问题在官方文档的教程中也提到过，就是说在消息发送到 RabbitMQ 之后，默认是没有落地磁盘的，万一 RabbitMQ 宕机了，这个时候消息就丢失了。
所以为了解决这个问题，RabbitMQ 提供了一个持久化的机制，消息写入之后会持久化到磁盘。
这样哪怕是宕机了，恢复之后也会自动恢复之前存储的数据，这样的机制可以确保消息不会丢失。
设置持久化有两个步骤：
- ***个是创建 Queue 的时候将其设置为持久化的，这样就可以保证 RabbitMQ 持久化 Queue 的元数据，但是不会持久化 Queue 里的数据。
- 第二个是发送消息的时候将消息的 deliveryMode 设置为 2，就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
但是这样一来可能会有人说：万一消息发送到 RabbitMQ 之后，还没来得及持久化到磁盘就挂掉了，数据也丢失了，怎么办?
对于这个问题，其实是配合上面的 Confirm 机制一起来保证的，就是在消息持久化到磁盘之后才会给生产者发送 ACK 消息。
万一真的遇到了那种极端的情况，生产者是可以感知到的，此时生产者可以通过重试发送消息给别的 RabbitMQ 节点。
消费端弄丢了数据
RabbitMQ 消费端弄丢了数据的情况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候 RabbitMQ 就会认为你已经消费成功了，这条数据就丢了。
对于这个问题，要先说明一下 RabbitMQ 消费消息的机制：在消费者收到消息的时候，会发送一个 ACK 给 RabbitMQ，告诉 RabbitMQ 这条消息被消费到了，这样 RabbitMQ 就会把消息删除。
但是默认情况下这个发送 ACK 的操作是自动提交的，也就是说消费者一收到这个消息就会自动返回 ACK 给 RabbitMQ，所以会出现丢消息的问题。
所以针对这个问题的解决方案就是：关闭 RabbitMQ 消费者的自动提交 ACK，在消费者处理完这条消息之后再手动提交 ACK。
这样即使遇到了上面的情况，RabbitMQ 也不会把这条消息删除，会在你程序重启之后，重新下发这条消息过来。
怎么保证 MQ 的高可用性?
使用了 MQ 之后，我们肯定是希望 MQ 有高可用特性，因为不可能接受机器宕机了，就无法收发消息的情况。
这一块我们也是基于 RabbitMQ 这种经典的 MQ 来说明一下：RabbitMQ 是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解***种 MQ 的高可用性怎么实现。
RabbitMQ 有三种模式：
- 单机模式
- 普通集群模式
- 镜像集群模式
单机模式
单机模式就是 Demo 级别的，就是说只有一台机器部署了一个 RabbitMQ 程序。
这个会存在单点问题，宕机就玩完了，没什么高可用性可言。一般就是你本地启动了玩玩儿的，没人生产用单机模式。
普通集群模式
这个模式的意思就是在多台机器上启动多个 RabbitMQ 实例。类似的 Master-Slave 模式一样。
但是创建的 Queue，只会放在一个 Master RabbtiMQ 实例上，其他实例都同步那个接收消息的 RabbitMQ 元数据。
在消费消息的时候，如果你连接到的 RabbitMQ 实例不是存放 Queue 数据的实例，这个时候 RabbitMQ 就会从存放 Queue 数据的实例上拉取数据，然后返回给客户端。
总的来说，这种方式有点麻烦，没有做到真正的分布式，每次消费者连接一个实例后拉取数据。
如果连接到不是存放 Queue 数据的实例，这个时候会造成额外的性能开销。如果从放 Queue 的实例拉取，会导致单实例性能瓶颈。
如果放 Queue 的实例宕机了，会导致其他实例无法拉取数据，这个集群都无法消费消息了，没有做到真正的高可用。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 Queue 的读写操作。
镜像集群模式
镜像集群模式才是真正的 RabbitMQ 的高可用模式，跟普通集群模式不一样的是：创建的 Queue 无论元数据还是 Queue 里的消息都会存在于多个实例上。
每次写消息到 Queue 的时候，都会自动把消息到多个实例的 Queue 里进行消息同步。
这样的话任何一个机器宕机了，别的实例都可以用来提供服务，这样就做到了真正的高可用了。
但是也存在着不好之处：
- 性能开销过高，消息需要同步所有机器，会导致网络带宽压力和消耗很重。
- 扩展性低：无法解决某个 Queue 数据量特别大的情况，导致 Queue 无法线性拓展。就算加了机器，那个机器也会包含 Queue 的所有数据，Queue 的数据没有做到分布式存储。
对于 RabbitMQ 的高可用一般的做法都是开启镜像集群模式，这样起码来说做到了高可用，一个节点宕机了，其他节点可以继续提供服务。
总结
通过本篇文章，分析了对于 MQ 的一些常规问题：
- 为什么使用 MQ?
- 使用 MQ 有什么优缺点?
- 如何保证消息不丢失?
- 如何保证 MQ 高可用性?
但是，这些问题仅仅是使用 MQ 的其中一部分需要考虑的问题，事实上，还有其他更加复杂的问题需要我们去解决。
比如：如何保证消息的顺序性?消息队列如何选型?消息积压问题如何解决?
本文仅仅是针对 RabbitMQ 的场景举例子。还有其他比较的消息队列，比如 RocketMQ、Kafka。
不同的 MQ 在面临上述问题的时候，要根据他们的原理机制来做对应的处理，这些都是本文没有顾及的内容，将在后面的文章中讨论。
