消息队列学习笔记

定义

首先，什么是消息队列？
消息队列，我们一般将其简称为MQ（Message Queue）。
它会将数据以日志的形式储存在磁盘里，MQ真正的目的是为了通讯,他屏蔽了复杂的通讯协议，像常用的dubbo，http协议都是同步的。
这两种协议很难实现双端通讯，A调用B,B也可以主动调用A，而且不支持长连接。mq做的就是在这些协议上构建一个简单协议——生产者、消费者模型，mq带给我们的不是底层的通讯协议，而是更高层次的通讯模型。他定义了两个对象：发送数据的叫做生产者，接受消息的叫做消费者，我们可以无视底层的通讯协议，我们可以自己定义生产者消费者。

作用

消息队列的三个最主要的作用是：异步、削峰、解耦
为了更好的理解这三个作用，我们假设一个场景，假如你的快递员要给你派送快递，你就相当于消费者，快递员就相当于生产者。在这个场景下快递员要把快递送到驿站，你可以随时去驿站取快递，中间的这个驿站就相当于消息队列。首先是解耦，原先如果没有驿站，快递员需要将快递亲自送到你的手上，二者是强耦合的，而现在有了驿站不需要亲自送到你手里了，只需要送到驿站就好了，你再去驿站取。然后是削峰，假设现在你有100个快递，如果没有驿站，而你此刻正好有事正好不能接收，那么快递员就必须等待你回来将快递送到你的手里，但是现在有了驿站，不管你有多少快递，放在驿站就好了，只要驿站够大就可以一直放，而你随时去取快递就可以，快递员也不用一直等待，这就是解耦。最后是异步，原先没有驿站，你接收快递必须你和快递员同时有空才可以接收该快递，现在有了驿站，快递直接放到驿站即可，不必彼此等待，这就是异步。
以上场景中，我利用比喻的形式解释了消息队列的作用。

消息队列具有这些队列，那么它通常会在什么情况下被使用呢。

假设一个购物平台在处理用户的购买操作时需要经过以下流程：

观察一下上面的设计，属于典型的串行化调用，这种设计模式有一个很大的优势，就是代码简单，出现问题很容易定位到问题。
如果说业务体量小，并发不大，可以使用这种设计

但是也有很多劣势，下面咱们从三高（高并发，高性能，高可用）三个方面去评审一下这个设计。
高可用：这些服务假如有一个服务挂掉（宕机或者网络波动），就意味着我这个请求失败了，这样用户体验会极差，用户会频繁看到支付失败。
高并发：因为这些操作都是由一个线程（主线程）去执行这些操作，所以当我们的QPS如果很高的话，很容易造成超时。
高性能：因为上面这种设计模式是串行的，假设我的每次网络传输耗时200ms，业务处理需要20ms，完成上面那些操作需要耗时2s，这样用户体验也会很差（想象一下每次下单都需要等2s）,如果用户下单后的操作越来越多，耗时只会越来越高。
所以在一个大型的互联网项目中，以上设计是完全不可取的（非核心模块除外）。

在这种情况下我们就可以采用消息队列的方式，将这种串行的设计改变为并行的设计。

依旧那快递的例子做比喻，现在用户下单就相当于快递员给人送快递，各种后台系统的调用就相当于各个用户取快递，中间的消息队列也就是驿站。现在用户下单后请求就可以将请求储存在消息队列中，然后直接返回，不需要再等待，随后消息队列再把请求给各个系统，让其并行执行。

咱们从继续从三高的层面去审视一下这个设计：
高可用：当我系统里的一个模块宕机了，不会影响到我其他服务。（可以通过数据补偿或者分布式事务来保证数据最终一致性）
高性能：用户下单，将下单所需要的数据都放到消息队列里，就直接返回了，所有耗时相当于就是网络传输所耗时。
高并发：由于消息队列不处理任何业务上的逻辑，所有他支持的并发是百万级别的。假如有100万个用户下单，100万的数据放到消息队列里，连接消息队列的服务慢慢消费即可，也不至于造成瞬间有百万请求进来，将我的服务压垮。

在这种场景下就十分适合使用消息队列。

优缺点

因此消息队列的有点就和它的作用一样，异步、削峰、解耦
他有优点，当然它也具有缺点。
消息队列的缺点：
1，增加了系统复杂性。
所以说如果说你的业务量不大，并发也不高，就没必要使用消息队列。
2，事务问题。
事务问题其实是分布式系统肯定会存在的一个问题，只不过消息队列更严重一些。一般解决方案有两种，第一种就是采用分布式事务，这个下单的里涉及的所有服务放到一个事务里面，要么都成功，要么都失败。第二种就是，消费者做好合理的数据补偿措施，比如说，消息重试，人工刷数据等等。
用了消息队列就代表接收了不实时性，只需保证最终一致性
3，可用性
刚才讲了解耦，其实是系统的各个模块之间的解耦，但是这些模块都和消息队列关联，万一消息队列挂了，就真的下不了单了。为了保证可用性，我们可以采用消息队列集群，前端流量限流等，后面会介绍。