消息队列中间件（Message Queue Middleware，MQ）：利用 可靠的消息传递机制 进行 与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过消息排队模型，它可以在 分布式环境下扩展进程间的通信。
消息队列中间件一般有两种传递模式：
点对点（P2P，Point-to-Point）模式
基于 队列，消息生产者发送消息到队列，消息消费者从队列中接收消息。
队列的存在使得消息的 异步传输成 为可能。
发布/订阅（Pub/Sub）模式
定义了如何向一个内容节点发布和订阅消息，内容节点称为 主题（topic），消息发布者将消息 发布到某个主题，而消息订阅者则 从主题中订阅消息。
该模式在 消息的一对多广播时采用
在不同的应用场景下有不同的作用，总的来说，可以概括如下：
解耦
对于项目的变化，很难预测到未来的变动。消息中间件在处理过程中间插入了一个隐含、基于数据的接口层，两边的处理过程都要实现这一接口，但是两边都可以独立的扩展或则修改自己的处理过程，只要 确保他们遵守同样的接口约束 即可。
冗余（存储）
某些情况下，处理数据的过程可能失败。消息中间件可以把数据持久化直到他们已经被完全处理，通过这一方式 规避了数据丢失的风险。
在把一个消息从中间件删除时，需要你明确的指出该消息已经被处理完成。
扩展性
因为 解耦了应用程序的处理过程，所以 提高消息入队 和 处理效率 就变得很容易了，只要增加额外的处理过程即可，不需要改变代码和参数
削峰
在访问量剧增的场景下，应用需要继续发挥作用，但是这样的突然流量并不常见。如果以能处理这类峰值为标准而投入资源（比如硬件），无疑是巨大的浪费。使用消息中间件能够使关键组件支持突发访问压力，不会因为突发的超负荷请求而完全崩溃。
可恢复性
当系统一部分组件失效时，不会影响到整个系统。当这部分组件被修复后，再连接上消息中间件，可以继续处理未处理完的消息。
顺序保证
大多数场景下，数据处理的顺序很重要，大部分消息中间件支持一定程度上的顺序性。
异步通信
在很多时候，应用不想也不需要立即处理消息。将消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比RocketMQ,Kafka低一个数量级 | 万级，比RocketMQ,Kafka低一个数量级 | 10万级，支持高吞吐 | 10万级，支持高吞吐 |
| Topic数量对吞吐量的影响 | Topic可以达到几百/几千量级 | Topic可以达到几百量级，如果更多的话，吞吐量会大幅度下降 | ||
| 时效性 | ms级 | 微秒级别，延迟最低 | ms级 | ms级 |
| 可用性 | 高，基于主从架构实现高可用 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高，分布式架构 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置，可以做到0丢失 |
| 功能支持 | MQ领域的功能极其完备 | 并发能力强，性能极好，延时很低 | MQ功能较为完善，分布式，扩展性好 | 功能较为简单，支持简单的MQ功能，在大数据领域被广泛使用 |
| 其他 | 很早的软件，社区不是很活跃 | 开源，稳定，社区活跃度高 | 阿里开发，社区活跃度不高 | 开源，高吞吐量，社区活跃度极高 |
一个topic的分区，只能被同一个消费者组里的一个消费者消费