个人理解哈，就是消息的排队，根据不同的主题将消息写到队列里面

9.jpg

一种先进先出的数据结构。。。。

常用的消息队列中间件

ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。

v2-984876e8232372b9e16180c68927a378_r.jpg

数据吞吐量来说 RocketMQ Kafka 非常强大 而ActiveMQ就比较弱了
从部署方式来看 RocketMQ Kafka 都是高可用的分布式部署，一个数据会有多个副本，保证数据不丢失，而且RocketMQ 是阿里的，不断迭代中，githup上有问题可以反馈啊

从这几点来说，要选择什么，就是看你数据的吞吐量嘛，一般的就用activeMQ就行了。。。

消息队列的使用场景

异步、削峰、解耦

异步

网上常用的例子就是网站用户的注册，用户注册的时候会去较校验用户名密码，发送注册的短信，发送注册信息到你的邮箱
如果采用串行的方式 ：
1.检验注册信息
2.发动邮件
3.发送邮件 。。

v2-f0a918e7424b7712bdd16a10ce63c99b_r.jpg

才算注册成功的话，那用户都不耐烦了呀，我去哦，要等那么久，完全可以优化嘛，用户将他的信息写入到结束了，发送短信和邮件可以在后面去做

3.jpg

就是注册这一步，我搞完了，直接就返回了，你们后面的事情就不关我的事了，自己去处理

削峰

我的理解就是 比如双11 淘宝的流量就会突然变的很大啊，就有可能把这个服务冲垮掉，所以先将请求写到消息队列里面，一条条去处理，不是并发同时处理，这样就保证了起码服务不会挂掉，如果消息队列太长了，超过限度了就给用户跳转到一个友好的错误界面，请客官稍后再试啊。。。

4.jpg

还有就是日志处理，程序不断产生日志，一下子太多的日志写入日志处理的应用的话，也可能导致日志处理应用会崩溃啊，所以就先将日志写入到队列中，比如EFK日志处理
fluentd:日志收集和处理，如果不经过消息队列的话，他就直接去收集日志然后写入到ES中去了，有时候日志很多，完全有可能阻塞了，导致后面的日志都写不进去，所以先写入到kafka中去，然后再一条条写到ES中

5.jpg

解耦

7.jpg

现在都微服务化了，电商系统内部肯定分为了N多的系统，有订单系统，库存系统，优惠卷，支付啊。。。
要是都通过接口的调用，完全耦合起来了，比如下单后，订单服务得去调用库存系统去减掉商品，确定后要去调用支付系统付钱。。。完全就耦合起来了，但是将数据写入到MQ中，就是我下单后其他我都不管，你库存系统自己去监听消息，支付系统去支付订单，然后你再告诉我支付成功，也可以写进队列里面，订单系统去监听就好了
当然没有再电商公司呆过不知道流程是不是这样的。。。

使用MQ后引申出来的问题

系统复杂性

系统变得很复杂，维护消息队列也变得比较复杂

数据一致性

订单系统下单成功了，但是库存系统没有读到消息，导致失败。。。我去，这怎么搞，所以说必须要保证数据这个链条是一致的才行，难点 难点

可用性

要是MQ挂了，怎么办？都不能用了，库存没减，支付不成功。。。。
想想都痛疼

这些问题该怎么解决，也再学习当中。。。。