MQ

消息队列 - 具有缓冲作用、具备发布和订阅能力的存储引擎
消息队列的最基本功能 - 生产 + 消费
标准消息队列 - 功能齐全
- 在发布订阅的基础上，高阶能力 - 死信队列、顺序消息、延时消息等
- 实现高吞吐、低延时、高可靠的特征

社区

RabbitMQ 于 2007 年开源，使用 Erlang，主要满足业务中消息总线的场景
特点为功能丰富（支持延时消息、死信队列、优先级队列、事务消息等），在低流量下稳定性较高
缺点 - 在大流量的情况下，会有明显的性能瓶颈和稳定性分险
ActiveMQ 基于 JMS 协议（国内较少使用），而 RabbitMQ 基于 AMQP 协议
AMQP 是消息队列协议规范，并非一款具体的消息队列
- 不同消息队列的访问协议是不一样的，导致不同的消息队列需要用到不同的 SDK 访问

RocketMQ 由阿里于 2013 年研发，2016 年开源，可满足大规模的微服务场景
- 功能丰富，基本可以满足业务消息场景下的所有需求
- 稳定性、数据可靠性表现较好
- 性能介于 RabbitMQ 和 Kafka 之间
- RocketMQ 的定位为 RabbitMQ 的升级版
功能
- RocketMQ 与 RabbitMQ 类似，功能丰富，常用于业务消息
- RocketMQ 在移动互联网浪潮下发展起来，场景更复杂，支持更多功能 - 消息 Tag、消息轨迹、消息查询等
架构+性能
- RabbitMQ 在设计时，分布式的设计理念不成熟，导致其在架构上存在较大缺陷
  - 在遇到大流量、高并发的时候，容易出现集群不可用、网络分区等情况
- RocketMQ 在分布式架构上实现得更合理优雅，在大流量、高并发的场景下表现优秀稳定

Pulsar 于 2017 年由 Yahoo 开发
- 一开始定位为流计算领域，同时发展消息和流两个方向
- 架构设计优秀 - 计算存储分离、弹性、多租户
- 在功能上，追赶 RabbitMQ 和 RocketMQ；在性能上，与 Kafka 相当，但稳定性有待提升
功能
- Pulsar 与 Kafka 类似，主要定位在流领域，主打大吞吐的流式计算
- Kafka 的功能相对简单，支持基本的发布订阅、幂等、事务消息
- Pulsar 在 Kafka 的基础上，有望支持 RocketMQ 和 RabbitMQ 功能，功能最为丰富
架构+性能
- Pulsar 的架构设计比 Kafka 更符合当下云原生架构
- Pulsar 的定位为 Kafka 的升级版，主要解决 Kafka 的一些痛点问题
  - 集群扩缩容慢
  - 分区迁移需要 Rebalance
  - 无法支持超多分区
- Pulsar 与 Kafka 目前没有特别大的性能差距
Pulsar 发展时间短且架构复杂，支持较多功能，稳定性不如 Kafka

	发展趋势
需求	消息 -> 流 -> 消息与流融合
架构	单机 -> 分布式 -> 云原生/Serverless

在 90 年代到 21 世纪初，以 AMQP 为代表的 MQ 主要满足业务上对消息的需求 - 异步通信 + 架构解耦
2010 年左右，移动互联网兴起，传统的 MQ 在架构上无法满足大流量高吞吐的需求 - Kafka - 分布式
随着场景越来越复杂，业务消息的数据量越来越大
- 基于 AMQP 的 RabbitMQ 在性能和架构上无法满足需求 - RocketMQ
随着云原生和 Serverless 的兴起，在弹性和成本的驱动下
- MQ 利用云上的弹性计算和存储等基础设施去实施架构上的 Serverless
- 按需使用、按量付费，最终达到免运维、低成本
随着云原生架构设计的 Pulsar 开始走向成熟，业界的 MQ 也出现了计算存储分离、分层存储、多租户、弹性计算等概念

概念
- 消息 - 即业务消息，在业务架构（微服务架构）中用来作为消息传递，作为系统的消息总线
- 流 - 在大数据架构中用来做大流量时的数据削峰
在业务消息中，经常使用 RocketMQ 或者 RabbitMQ，而在大数据系统中，经常使用 Kafka 或者 Pulsar - 更高的研发和运维成本

MQ	Message + Streaming
~~RabbitMQ~~	因为开发语言、架构和社区的活跃度和定位等原因，基本不会走这个方向
Kafka	虽然强调云原生，但主要工作在自身的架构优化上（如移除 ZooKeeper），在消息方向暂时没有提出明确的概念
RocketMQ	在消息领域已经非常成熟，社区希望打通流的场景
Pulsar	新兴架构，没有历史包袱，主打云原生的消息和流的融合架构，希望满足更多场景，解决更多业务需求