上一篇我們用一個秒殺案例探討了我們為什么需要消息隊列。今天我們來回顧一下消息隊列的發展歷史。

下圖列出了過去 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 看起來是這樣的

{type}://{tenant}/{namespace}/{topic}

值得注意的是，URI 中有一個租戶元素，這意味著 Pulsar 支持多租戶環境。

Pulsar 還支持持久化或非持久化的訂閱主題。持久化主題在磁盤上持久存在，而非持久化主題則駐留在內存中，一旦發生故障可能會丟失。

Pulsar 架構分為兩層：服務層和持久層。服務層由多個消息代理組成，負責處理傳入和傳出的信息。服務層是無狀態的，它利用 Apache BookKeeper 來存儲信息。

另一個有趣的設計是，Pulsar 原生支持分層存儲，我們可以用 AWS S3 等更便宜的對象存儲來長期持久地保存消息。

總結一下，消息隊列的發展從一開始的消息傳遞中間件演進為流處理。現代消息隊列通常將這兩種功能結合在一起，并支持分布式環境中的容錯。我們用下圖來結束今天的日拱一卒：每種流行產品的誕生都改變了消息隊列的編程范式，并解決了業務痛點。

審核編輯：湯梓紅