上一篇我们用一个秒杀案例探讨了我们为什么需要消息队列。今天我们来回顾一下消息队列的发展历史。
下图列出了过去 30 年中消息队列的发展简史。
我们来依次介绍一下这些产品。
IBM MQ
IBM MQ 于 1993 年推出。它最初称为 MQSeries，2002 年更名为 WebSphere MQ。2014 年更名为 IBM MQ。IBM MQ 是一款非常成功的产品，广泛应用于金融领域。到 2020 年，其收入仍将达到 10 亿美元。下图显示了 IBM MQ 的关键架构。
队列管理器（Queue Manager）是消息队列的逻辑容器。它通过消息通道（channel）向其他队列管理器传输数据。传输的数据抽象为“消息”这个概念。队列用来存储消息。消息头包含路由信息、存储方式和传递目标信息。
还有其他一些非开源消息队列，如 MSMQ（1997 年）和 SQS（2004 年），它们都在各自的生态系统中发挥了很好的作用。
RabbitMQ
2003 年，多家金融机构希望开发一种标准化的消息传递协议，于是 AMQP（Advanced Message Queuing Protocol）在摩根大通诞生了。与在 API 层面标准化的 JMS（Java Messaging Service）不同，AMQP 是一种 wire level 的协议，这意味着它规定了要传输的数据格式。作为 AMQP 的一种实现，RabbitMQ 由 Rabbit Technologies 于 2007 年开发，后被 VMWare 收购。
下图是 RabbitMQ 的架构。我们可以看到，它与 IBM MQ 不同，更类似于 Kafka 的架构概念。生产者向交换中心发布消息。它可以是直接交换、基于主题交换或扇出。然后，交换中心根据不同的消息属性和交换类型将消息路由到队列中。消费者据此接收信息。
虽然 RabbitMQ 拥有很多现代消息队列概念，但它是近 20 年前开发的。当时的分布式系统还不像现在这样成熟，因此该架构在处理大流量和大量并发请求的场景时受到了限制。
Kafka
2011 年初，LinkedIn 开源了分布式事件流平台 Kafka。它以作家 Franz Kafka 的名字命名。顾名思义，Kafka 是为写而优化的。它为处理实时数据流提供了一个高吞吐量、低时延的平台。它提供了一个统一的事件日志（event log）来实现事件流，在互联网公司中得到广泛应用。下图是简化的 Kafka 架构。
总的来说，Kafka 定义了生产者、消息代理、订阅主题、分区和消费者。Kafka 的简单性和容错性使其能够取代以前的产品，如基于 AMQP 的消息队列。
Pulsar
Pulsar 最初由雅虎开发，是一个一体化的消息平台和流平台。与 Kafka 相比，Pulsar 融合了其他产品的许多实用功能，支持的功能范围更广。此外，Pulsar 的架构更具云原生性，可为集群扩展和分区迁移等提供更好的支持。下图显示了 Pulsar 架构的简化版本。
与 Kafka 类似，Pulsar 也有订阅主题的概念，其 URI 看起来是这样的
代码语言：javascript复制 {type}://{tenant}/{namespace}/{topic}
值得注意的是，URI 中有一个租户元素，这意味着 Pulsar 支持多租户环境。
Pulsar 还支持持久化或非持久化的订阅主题。持久化主题在磁盘上持久存在，而非持久化主题则驻留在内存中，一旦发生故障可能会丢失。
Pulsar 架构分为两层：服务层和持久层。服务层由多个消息代理组成，负责处理传入和传出的信息。服务层是无状态的，它利用 Apache BookKeeper 来存储信息。
另一个有趣的设计是，Pulsar 原生支持分层存储，我们可以用 AWS S3 等更便宜的对象存储来长期持久地保存消息。
总结一下，消息队列的发展从一开始的消息传递中间件演进为流处理。现代消息队列通常将这两种功能结合在一起，并支持分布式环境中的容错。我们用下图来结束今天的日拱一卒：每种流行产品的诞生都改变了消息队列的编程范式，并解决了业务痛点。
