MQ消息队列简要

MQ消息队列

什么是消息队列

消息队列就像是一个放东西的容器，当我们需要读取消息的时候就自己取出来供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是通过异步处理提高系统性能和削锋、降低系统耦合性

为什么要使用消息队列

解耦、异步、削峰

A系统调用B系统、C系统，传统的调用是直接调用，但是当B系统说我不需要你提供数据了，这时候A需要改代码，Ｃ系统说我不需要某个字段了，这时候Ａ也要改代码，如果又多了一个D系统，A又要写代码。为了实现解耦，引入消息队列，Ａ将产生的数据丢到消息队列中，哪个系统需要　哪个系统就去取；
A系统调用B系统，B系统由于某个需要调用第三方接口超时，导致A系统响应速度慢，而B系统的好坏又不会影响业务逻辑，所以可以改为A异步调用B，A将消息丢到消息队列中，B系统订阅消息，实现A的快速响应；
当大量流量请求到系统A时，由于数据库的处理能力有限，造成数据库连接异常。使用消息队列，大量请求先丢到消息队列中，系统A使用按批拉数据的方式，批量处理数据，生产中，高峰期短暂的消息积压是允许的。

消息队列的缺点

系统可靠性降低，解耦后，多个系统通过消息中间件交互，消息中间件挂了整个系统就挂了；
系统开发复杂度提升，需要考虑消息的处理，包括消息幂等性（重复消费问题），消息保序性（一个订单多条消息问题），以及消息中间件本身的持久化和稳定性可靠性；
消息一致性问题，如果一个功能发给多个系统，要所有系统都执行成功才算成功时，需要确保一个功能多个消息的完整一致性；

各种MQ的的比较

特性	activeMQ	rabbitMQ	rocketMQ	kafka
单机吞吐量	万/秒	万/秒	10万/秒	10万/秒
topic对吞吐量的影响	无	无	topic达到几百/几千个级别，吞吐量会有小幅下降；这是rocket的最大优势，所以非常适用于支撑大批量topic场景	topic可以达到几十/几百个级别，吞吐量会有大幅下降 kafka不适用大批量topic场景，除非加机器
时效性	毫秒	微秒这是rabbit 最大优势，延迟低	毫秒	毫秒
可用性	高。主从架构	高。主从架构	非常高。分布式。	非常高。分布式。
可靠性	-----	有较低概率丢失数据	经配置优化可达到0丢失	经配置优化可达到0丢失
功能特性	功能齐全，但已不怎么维护	erlang开发，并发强，性能极好，延迟低	MQ功能较为齐全，扩展好	功能简单，主要用于大数据实时计算和日志采集，事实标准

综上，总结如下：

【activeMQ】

优点：技术成熟，功能齐全，历史悠久，有大量公司在使用
缺点：偶尔会有较低概率丢失数据，而且社区已经不怎么维护5.15.X版本
使用场景：主要用于系统解耦和异步处理，不适用与大数据量吞吐情况。互联网公司很少适用
【rabitMQ】

优点：吞吐量高，功能齐全，管理界面易用，社区活跃，性能极好，；
缺点：吞吐量只是万级，erlang难以二次开发和掌控；集群动态扩展非常麻烦；
使用场景：吞吐量不高而要求低延迟，并且不会频繁调整和扩展的场景。非常适合国内中小型互联网公司适用，因为管理界面非常友好，可以在界面进行配置和优化/集群监控。
【rocketMQ】

优点：支持百千级大规模topic。吞吐量高（十万级，日处理上百亿）。接口易用。，分布式易扩展，阿里支持。java开发易于掌控。
缺点：与阿里（社区）存在绑定。不兼容JMS规范。
使用场景：高吞吐量
【kafka】

优点：超高吞吐量，超高可用性和可靠性，分布式易扩展
缺点：topic支持少，MQ功能简单，消息可能会重复消费影响数据精确度
使用场景：超高吞吐量场景而数据精确度没那么高，天然适合大数据实时计算和日志采集场景