中间件：MQ学习总结（持续更新）

中间件：MQ学习总结（持续更新）

MQ叫消息队列：
那么什么是消息队列？任何一门技术的出现一定是为了解决某个问题的。
先抛出问题吧。
在互联网技术发展的初期，业务的体量很小，那么在体量很小的时候，比如用户下单，直接代码从上至下同步执行完成，最后付款成功，假定整个过程花费50ms。而随着时间推移，业务开始丰富起来，比如在付款的时候加上优惠券，那么这个时候，再付款的中途还要去把优惠券减去，假设这个过程需要5ms，那么总用时就是55ms了，加入后面业务又增加了，付款还要以短信的形式通知用户付款成功，假设为5ms，那么就60ms，然后再加个什么付款成功赚积分，那么时间又会增加。假如只是下单成功，这一个业务流程就涉及到10几个这样的流程，那么就会导致很慢，用户体验不好，没人用你的系统。

那么为了解决上面流程多导致同步执行一个主流程需要耗时太久的问题，人们就想能不能异步来做，比如用户下单成功之后直接就返回成功，减优惠券，短信通知，减积分这些都用单独的子流程异步去做，这样就50ms就完成了。子流程只要从一个地方获取到下单成功的信息，然后各自去做响应的动作。

那么这个地方就是消息队列，就是一个中间件，下单成功的消息发送到消息队列中，自己也返回给用户下单成功，而子模块同时去消费这些消息，这样就完美的解决了这个问题。

但是，你肯定会问，你下单成功了，返回给用户成功，但是子流程中万一有失败的，不久乱套了吗？

是的，是会有这个问题，但是模块之间是解耦（这也是消息队列的一个作用）的，各自负责各自的模块，尽可能的保证不会出问题，如果真的出问题了，那么有没有什么解决办法呢，是有的！

分布式事务。这里就不说了。

消息队列的另外一个作用，就是可以削峰。说人话，就是比如在双十一的时候，凌晨那一刻，流量疯狂的打到服务器上，服务器肯定承受不住，那么消息队列的出现就可以在高并发大流量的数据上来的时候不直接到服务器，而是放到消息队列中，多个服务器根据自己的能力进行消费和处理，最坏的情况是比较慢而已，过了这个峰值就会变好，不至于出现服务器直接挂掉。
所以削峰就是把某一段时间的高并发大流量的数据进行引流到消息队列中，分批的执行。从而可以解决峰值导致的服务器不工作。

目前市面上MQ的类型有RabbitMQ、ActiveMQ、RocketMQ、Kafka.
RabbitMQ：开发语言是Erlang，公司是Mozilla。。。特点是“高并发,，不支持消息批量处理，支持高可用，吞吐量：万级

ActiveMQ：开发语言是Java，公司是apache，支持消息的批量处理，支持高可用，吞吐量：万级
RocketMQ：开发语言是Java ，公司是ali，支持消息的批量处理，支持高可用，吞吐量：十万级
kafka：开发语言是：java和Scala，公司是apache，支持消息的批量处理，支持高可用，吞吐量：十万级

消息延迟：依次：
RabbitMQ：微妙级
ActiveMQ
RocketMQ：比Kafka快
Kafka：毫秒级

持久化能力：
RabbitMQ：内存、文件
ActiveMQ：内存、文件
RocketMQ：磁盘文件
Kafka：磁盘文件

总结：
RabbitMQ：稳定可靠性，数据一致，支持多协议，有消息确认，基于erlang语言。
Kafka：高吞吐，高性能，快速持久化，无消息确认，无消息遗漏，可能会有重复消息，依赖于zookeeper，成本高。
ActiveMQ:不够灵活轻巧，对队列较多情况支持不好‘
RocketMQ：性能号，高吞吐，高可用性，支持大规模分布式，协议支持单一。

目前github上活跃度靠前的：RocketMQ 和 kafka。