MQ - 01 消息队列发展史&MQ通用架构

@[toc]

导图

Pre

MQ - 闲聊MQ一二事儿 （Kafka、RocketMQ 、Pulsar ）

MQ 发展史

基于 JMS 协议发展出来的 ActiveMQ 因为功能和稳定性问题，用的人比较少。

AMQP 是一个消息队列协议规范，它不是一款具体的消息队列。因为不同消息队列的访问协议是不一样的，导致不同的消息队列需要用不同的 SDK 访问，客户的切换成本很高。2003 年，多个金融服务机构希望制定一个消息队列的协议规范，希望不同的消息队列的协议都根据这个标准实现，这样就可以不需要重复开发 SDK，不同的应用程序之间的交互和切换可以更简单、更方便。这就是 AMQP 的由来。

基于 JMS 协议发展出来的 ActiveMQ 因为功能和稳定性问题，用的人比较少

ActiveMQ 项目最初是由 LogicBlaze 的创始人于 2004 年创建的，支持完成 JMS 规范的消息队列。因为生态、功能定位方面的原因，在国内用的人并不多。

RabbitMQ 是 2007 年由国外一家叫做 Rabbit 的公司开源的，用 Erlang 写成的消息队列。主要满足业务中消息总线的场景。特点是功能丰富，低流量下稳定性较高，基本具备消息队列所应该具备的所有功能。缺点是在大流量的情况下会有明显的瓶颈和稳定性风险。

AMQP 协议的 Erlang 实现 RabbitMQ，因为功能丰富，稳定性较高，成为当时的主流选择。

RocketMQ 在定位上和 RabbitMQ 很像，功能丰富，在业务消息中经常会用到。不过 RocketMQ 是在移动互联网浪潮下发展起来的，业务场景更加复杂，也支持更多功能，比如消息 Tag、消息轨迹、消息查询等等. RocketMQ 在分布式架构上实现得更合理优雅，在大流量、高并发的场景下表现优秀稳定

Pulsar 和 Kafka 很像，主要定位在流领域，主打大吞吐的流式计算。但 Kafka 的功能比较简单，支持基本的发布订阅、幂等、事务消息。Pulsar 在满足这些功能的基础上，也希望支持 RocketMQ 和 RabbitMQ 的功能，所以功能最丰富。

除了功能层面，在架构和性能层面上，Pulsar 的架构设计比 Kafka 更符合当前云原生架构，它的定位是 Kafka 的升级版，主要解决 Kafka 当前的一些痛点问题，比如集群扩缩容慢、分区迁移需要 Rebalance、无法支持超多分区等。性能目前没有特别大的差距。

不过 Pulsar 发展时间较短，架构较复杂，功能支持较多，当前阶段在稳定性上 Kafka 会比 Pulsar 好非常多。

Pulsar 2017 年由 Yahoo 开发的消息队列系统。一开始定位是流计算领域，可以理解为 Kafka 的升级版，近期希望同时发展消息和流两个方向。其架构上的设计理念较为优秀，比如计算存储分离、弹性、多租户。在功能上目前正在追赶 RabbitMQ/RocketMQ。性能层面，和 Kafka 没有明显的差异。但当前阶段的稳定性还需要提升。

消息队列的发展脉络

1. 消息队列的发展趋势：

• 需求发展路径：消息 -> 流 -> 消息和流融合。
• 架构发展趋势：单机 -> 分布式 -> 云原生 / Serverless。

2. 发展历史：

• 90年代到21世纪初，以IBM MQ和AMQP为代表的消息队列主要满足业务上对消息的需求，即异步通讯和架构解耦。
• 2010年左右，移动互联网和大数据兴起，传统的消息队列无法满足大流量需求，出现了以Kafka为代表的消息队列，主打大吞吐和大流量。进入了分布式时代，引入了分区、副本和一致性概念。
• 随着业务场景复杂化和数据量增加，RabbitMQ已无法满足消息场景需求，因此发展出了RocketMQ。
• 近几年，随着云计算、云原生和Serverless的兴起，消息队列架构朝着云原生/Serverless方向演进，利用云上的弹性计算和存储，实现免运维和低成本。

3. 云原生趋势：

• Pulsar是基于云原生架构设计的消息队列，强调云原生的消息和流的融合架构，以满足更多场景和需求。
• 业界的消息队列产品出现了计算存储分离、分层存储、多租户、弹性计算等概念。

MQ选型考虑因素

消息队列的选择与业务需求和数据量相关。在选择消息队列时，需要考虑以下因素：

1. 业务需求：首先，要明确你的业务需要什么样的消息队列功能。例如，是否需要支持延时消息、死信队列、事务消息等高级功能，还是只需要基本的生产和消费功能。
2. 数据量：考虑你的数据量是否大，是否需要高吞吐率和持久性。如果数据量较小，可以考虑使用非标准消息队列产品，如Redis或MySQL，以减少复杂性和成本。
3. 架构和性能需求：如果你的业务涉及大消息和大流量，需要考虑选择具有高吞吐率、高并发、持久性和稳定性的消息队列产品，如Kafka或Pulsar。
4. 云原生和Serverless需求：随着云计算的发展，云原生和Serverless架构变得越来越重要。一些消息队列产品开始朝这个方向演进，因此你可能需要考虑是否需要与云原生或Serverless架构集成。
5. 生态系统：考虑消息队列产品的生态系统和社区活跃度。一个活跃的生态系统通常会提供更多的支持和工具。
6. 成本：最后，要考虑成本因素。不同的消息队列产品在许可费用、维护成本和学习成本方面有所不同，需要根据你的预算和资源来选择合适的产品。

总之，消息队列的选择应根据具体的业务需求和场景来确定，不一定需要使用标准消息队列产品，非标准消息队列产品在某些情况下也可以满足需求。最重要的是要理解自己的需求并根据实际情况做出明智的选择。

消息 和 流

• 消息和流的定义：消息用于业务架构中的消息传递和系统消息总线，而流则在大数据架构中用于处理大流量数据，例如日志投递流转。
• 消息和流的融合趋势：消息和流的融合趋势是因为两者都有市场需求，但主要是出于经济原因。消息队列提供了缓冲和传递功能，但市场已经细分，Kafka在流领域占主导地位，RabbitMQ和RocketMQ在消息领域领先。
• 竞争和成本驱动：消息队列供应商需要提供独特的竞争力，包括更丰富的功能和更低的成本，以扩大市场份额或推出新产品。成本指的是为消息队列使用者节省的资源和人力成本。
• 运维和开发成本：使用者需要在业务消息和大数据系统中使用不同的消息队列，这增加了运维和开发的成本。如果一种消息队列可以满足所有需求，将会降低成本。
• 主流消息队列的融合动向：

• RabbitMQ不太可能走消息和流融合的路线，因为其定位和架构不太适合。
• Kafka目前主要致力于自身架构的优化，但未来可能会朝着消息和流融合方向发展。
• RocketMQ已经成熟在消息领域，也在朝着流的场景扩展努力。
• Pulsar是一个新兴架构，专注于云原生的消息和流融合，以满足更多场景和需求。

消息队列的架构和功能

什么情况下会使用消息队列？

• 消息队列的主要作用是解耦上下游系统、数据缓冲、分发消息、提高性能和可靠性。
• 消息队列的核心操作是生产和消费数据。
• 使用消息队列的常见场景包括系统解耦、数据缓冲、需要消息队列特性的情况（如延时消息、优先级消息）等。
• 典型使用场景包括订单下单流程和日志采集流程，其中消息队列的特性包括高性能、高吞吐、低延时。

架构和功能的基本概念

架构层面的基本概念

• Broker：消息队列中的进程，通常表示一个节点。
• Topic（主题）：用于组织分区关系的逻辑概念。
• Partition/Queue/MessageQueue（分区/分片）：数据存储的最小单位，一个Topic通常包含多个分区。
• Producer（生产者）：消息发送方，即生产消息的客户端。
• Consumer（消费者）：消息接收方，即消费消息的客户端。
• ConsumerGroup/Subscription（消费分组/订阅）：用于组织消费者和分区关系的逻辑概念。
• Message（消息）：业务数据。
• Offset/ConsumerOffset/Cursor（位点/消费位点/游标）：消费者消费分区的进度。
• ACK/OffsetCommit（确认/位点提交）：提交消费进度的操作。
• Leader/Follower（领导者/追随者，主副本/从副本）：分区的主从副本概念。
• Segment（段/数据分段）：消息数据在底层存储时的文件单位。
• StartOffset/EndOffset（起始位点/结束位点）：分区内消息的写入位置范围。
• ACL（访问控制技术）：用于资源权限控制。

功能层面的基本概念

• 顺序消息：保证消息按照发送顺序进行消费。
• 延时消息/定时消息：消息在一定时间后或指定时间才能被消费。
• 事务消息：一批操作要么一起成功，要么一起失败。
• 消息重试：生产者和消费者都支持消息发送和处理失败后的重试。
• 消息回溯：消息可以被多次消费。
• 广播消费：一条消息可以被多个消费者消费。
• 死信队列：处理消费失败的消息。
• 优先级队列：消息可以设置优先级。
• 消息过滤：根据标签信息过滤消息。
• 消息过期/删除（TTL）：消息在一定时间或大小后自动删除。
• 消息轨迹：记录消息生命周期的流程信息。
• 消息查询：根据某些信息查询消息。
• 消息压缩：支持消息压缩以节省资源。
• 多租户：实现集群内的逻辑隔离。
• 消息持久化：消息是否持久化存储。
• 消息流控：对消息写入集群进行限流。

4款主流消息队列的区别和建议

1️⃣