消息队列(MQ)概述
消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：
当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。
消息队列主要解决了应用耦合、异步处理、流量削锋等问题。
消息队列的应用场景
传统的消息队列的主要应用场景包括：缓存/肖锋、解耦和异步通信。
缓存/肖锋：
缓存/肖锋：有利于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
比如有下面这种情况：我们在大型活动中比如像双十一这样的活动。比如双十一参与的用户，每秒可以达到10亿/s,来进行一次秒杀，但是我们后台的最大的处理能力只有1千万/s，但是我这个系统扛不住这个海量的数据，但是我还要搞这次活动怎么办，那么我们就可以使用消息队列来处理。
解耦：
解耦：允许在消息队列两边修改或者是独立拓展处理，只需要确保他们遵循MQ统一的约束接口就行。
比如我们需要将我们的多个数据源如MySQL、MongoDB等传送到我们的数据处理框架中如SpringBoot、Spark中。如果没有消息队列的话，那我们就要对他们进行一一处理，编写相应的框架代码，这样开发成本很高、而且后续的修改也需要一一修改，这样麻烦。但是如果我们有了消息队列，我们的数据源只需要往消息队列里面写数据就行了，然后我们后端处理框架需要数据的，只需要从MQ中去取就行了，这样就减少了开发成本，有一个解耦的作用。
异步处理：
异步处理区别于同步处理
同步处理就是一步一步把所有的事情都给做完，比如我们用户填写注册信息，然后后台将用户信息写入数据库，然后在调用发送短信接口来发送短信，假设发送短信这个过程需要等待3秒，然后之后页面才响应注册成功。
Kafka
Kafka是一个基于分布式的、具有高吞吐量的发布、订阅模式的消息队列，主要应用于大数据领域，它可以承担大数据的存储、分析和计算。
主要特性：
快速持久化，可以在O(1)的系统开销下进行消息持久化；
高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
支持同步和异步复制两种HA；
支持数据批量发送和拉取；
zero-copy：减少IO操作步骤；
数据迁移、扩容对用户透明；
无需停机即可扩展机器；
其他特性：严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制；
优点：
1.客户端语言丰富，支持java、.net、php、ruby、python、go等多种语言；
2.性能卓越，单机写入TPS约在百万条/秒，消息大小10个字节；
3.提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积；
4.支持批量操作；
5.消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
6.有优秀的第三方Kafka Web管理界面Kafka-Manager；
7.在日志领域比较成熟，被多家公司和多个开源项目使用；
缺点：
1.Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
2.使用短轮询方式，实时性取决于轮询间隔时间；
3.消费失败不支持重试；
4.支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
5.社区更新较慢；
RabbitMQ（BMQ）
RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
主要特性：
可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；
灵活的路由： 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；
消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；
队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；
多种协议的支持：支持多种消息队列协议；
服务器端用Erlang语言编写，支持只要是你能想到的所有编程语言；
管理界面: RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；
跟踪机制：如果消息异常，RabbitMQ提供消息跟踪机制，使用者可以找出发生了什么；
插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；
优点：
由于erlang语言的特性，mq 性能较好，高并发；
健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
有消息确认机制和持久化机制，可靠性高；
高度可定制的路由；
管理界面较丰富，在互联网公司也有较大规模的应用；
社区活跃度高；
缺点：
尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
需要学习比较复杂的接口和协议，学习和维护成本较高；
RocketMQ
RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
主要特性：
是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；
Producer、Consumer、队列都可以分布式；
Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合；
能够保证严格的消息顺序；
提供丰富的消息拉取模式；
高效的订阅者水平扩展能力；
实时的消息订阅机制；
亿级消息堆积能力；
较少的依赖；
优点：
单机支持 1 万以上持久化队列。
RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。
模型简单，接口易用（JMS 的接口很多场合并不太实用）；
性能非常好，可以大量堆积消息在broker中；
支持多种消费，包括集群消费、广播消费等。
各个环节分布式扩展设计，主从HA；
开发度较活跃，版本更新很快。
缺点：
支持的客户端语言不多，目前是java及c++，其中c++不成熟；
RocketMQ社区关注度及成熟度也不及前两者；
没有web管理界面，提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题；
没有在 mq 核心中去实现JMS等接口；
内容参考网络多个博主的博客和百度。
