本文轉自騰訊雲中間件，作者張超，騰訊數據平台部 MQ 團隊高級工程師，Apache TubeMQ(incubating) PMC，Kafka-on-Pulsar Maintainer，Apache Pulsar Contributor
騰訊數據平台數平 MQ 團隊對 Pulsar 做了深入調研以及大量的性能和穩定性方面優化，目前已經在騰訊雲消息隊列 TDMQ 落地上線。本文主要簡單梳理了 Pulsar 支持的一些傳統消息隊列應用場景，以及 Pulsar 新特性對更多場景的支持。關於 Apache Pulsar
Apache Pulsar 是 Apache 軟件基金會頂級項目，是下一代雲原生分布式消息流平台，集消息、存儲、輕量化函數式計算為一體，采用計算與存儲分離架構設計，支持多租戶、持久化存儲、多機房跨區域數據復制，具有強一致性、高吞吐、低延時及高可擴展性等流數據存儲特性。
GitHub 地址：http://github.com/apache/pulsar/
消息隊列概述
什么是消息隊列
消息隊列（Message Queue，簡稱MQ），是指在消息的傳輸中保存消息的容器或服務，是一種異步的服務間通信方式，適用於無服務器和微服務架構，是分布式系統實現高性能、高可用、可伸縮等高級特效的重要組件。
常見的主流消息隊列有 ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ、Pulsar 等。而在公司內有 TubeMQ、Ckafka、TDMQ、CMQ、CDMQ、Hippo 等。
消息隊列特點
分布式
消息隊列都是分布式的，因此才可以提供異步、解耦等功能。
可靠性
基於消息的通信是可靠的，消息不會丟失。大多數消息隊列都提供將消息持久化到磁盤的功能。
異步
通過消息隊列，可將遠程同步調用拆解成為異步調用。對於不需要獲取遠程調用結果的應用場景來說，性能提升明顯。
松耦合
消息直接由中間件存儲和分發。消息生產者只需關注如何將消息發送給消息中介服務器；消費者只需關注如何從中介服務器訂閱。生產者和消費者之間是完全解耦的，不需要知道彼此的存在。
事件驅動
可以將復雜的應用系統重構成為事件驅動的系統。事件溯源（Event Sourcing），表示一個對象從創建到消亡，會經過的多種狀態。如果把對象的狀態變化都存儲下來，不但可以根據狀態變化記錄獲取對象的當前狀態，也可以回溯對象的變化過程。消息隊列能很好地支持這樣的系統設計方式，將觸發對象狀態變化的事件放入消息隊列。
消息隊列分類
在 JMS（JAVA Message Service）標准中，有P2P（Point to Point）和 Publish/Subscribe(Pub/Sub) 兩種消息模型。
P2P
P2P的特點是每個消息只有一個消費者。消息生產者將消息發送到消息隊列（Queue）中，只有一個消費者能夠消費此消息，消費完成之后消息即刪除。任意一個消費者都可以消費這個消息，但消息絕對不會被兩個消費者重復消費。
Pub/Sub
Pub/Sub 的特點是發布到 Topic 的消息會被所有訂閱者消費。消息生產者將消息發送到消息主題（Topic）中，所有訂閱這個主題的消費者都可以消費此消息，當所有訂閱者都消費完成之后才能刪除消息。
消息的生產者和消費者之間有時間依賴，只有事先訂閱這個主題的消費者才可消費。如果先發送消息，后訂閱主題，那么訂閱之前的消息將不能被這個訂閱者消費。
傳統企業型消息隊列 ActiveMQ 遵循了 JMS 規范，實現了點對點和發布訂閱模型，但其他流行的消息隊列 RabbitMQ、Kafka 並沒有遵循 JMS 規范。
而在實時流式架構中，消息隊列的消息傳遞可以分為隊列（Queue）和流（Stream）兩類。
隊列（Queue）模型
隊列模型主要是采用無序或者共享的方式來消費消息。通過隊列模型，用戶可以創建多個消費者從單個管道中接收消息；當一條消息從隊列發送出來后，多個消費者中的只有一個（任何一個都有可能）接收和消費這條消息。消息系統的具體實現決定了最終哪個消費者實際接收到消息。
隊列模型通常與無狀態應用程序一起結合使用。無狀態應用程序不關心排序，但它們確實需要能夠確認（ACK）或刪除單條消息，以及盡可能地擴展消費並行性的能力。典型的基於隊列模型的消息系統包括 RabbitMQ 和 RocketMQ。
流式（Stream）模型
相比之下，流模型要求消息的消費嚴格排序或獨占消息消費。對於一個管道，使用流式模型，始終只會有一個消費者使用和消費消息。消費者按照消息寫入管道的確切順序接收從管道發送的消息。
流模型通常與有狀態應用程序相關聯。有狀態的應用程序更加關注消息的順序及其狀態。消息的消費順序決定了有狀態應用程序的狀態。消息的順序將影響應用程序處理邏輯的正確性。典型的基於流模型的消息系統包括 Kafka、TubeMQ。
傳統消息隊列的應用場景
異步調用
假設有一個系統調用鏈路為 A 調用 B 耗時 20ms，B 調用 C 耗時 20ms，而 C 調用 D 需要 2s，這樣下來整個調用需要耗時 2040ms。但實際上 A 調用 B，B 調用 C 只需要 40ms，而 D 系統的引入直接導致系統性能下降約 50 倍。此時我們可以考慮引入消息隊列，將 D 系統的調用抽離出來，做一個異步調用：系統 A 到系統 B 再到系統 C 后就直接結束，系統 C 將消息發送到消息隊列中，系統 D 從消息隊列里取消息進行消費，這樣子我們系統的性能就提高了接近 50 倍。
系統解耦
各個業務系統僅需要處理自己的業務邏輯，發送事件消息到消息隊列。下游業務系統直接訂閱消息隊列的隊列或主題獲取事件。消息隊列可用於單體應用被拆解為微服務后不同微服務間的通信。系統解耦的好處是不同系統的迭代不再相互依賴，能有效縮短數據鏈路長度，提高數據處理效率。
削峰填谷
大型活動帶來較高流量時，沒有做好相應保護容易導致系統超負荷甚至崩潰，而限制太過則會導致請求大量失敗而影響用戶體驗。消息隊列服務擁有高性能的消息處理能力，可以承接流量脈沖而不被擊垮，在確保系統可用性的同時，通過快速有效的請求響應技術提升用戶體驗。其海量消息堆積能力確保下游業務在安全水位內平滑穩定的運行，避免流量高峰的沖擊。
廣播通知
系統一個狀態的改變，需要通知多個相關系統，可通過消息訂閱的方式推送給各個訂閱者系統。比如數據庫值的改變，需要通知所有的緩存系統更新，可以把數據庫值改變發送消息給消息隊列，然后各緩存訂閱相關主題，收到消息后更新自己的緩存。
分布式緩存
在大數據場景中，日志分析往往需要處理大量日志，不可能存儲在一台物理機上。消息隊列可提供一個集群，用來存儲海量消息，將其緩存到消息隊列，進一步供實時分析系統分析日志。Kafka 和 TubeMQ 在大數據處理中往往充當分布式緩存的作用。
消息通訊
消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
Pulsar的應用場景
Pulsar 作為新一代存儲計算分離架構的消息隊列服務，不僅適用於上面提到的傳統消息隊列的應用場景，它的一些新特性還為更多應用場景帶來可能。
隊列和流的融合—維護一套 MQ 服務就夠了
Apache Pulsar 抽象出了統一的 producer-topic-subscription-consumer 消費模型，既支持隊列模型，也支持流模型。在 Pulsar 的消息消費模型中，Topic 是用於發送消息的通道。每一個 Topic 對應着 Apache BookKeeper 中的一個分布式日志。發布者發布的每條消息只在 Topic 中存儲一次；存儲的過程中，BookKeeper 會將消息復制存儲在多個存儲節點上；Topic 中的每條消息，可以根據消費者的訂閱需求，多次被使用，每個訂閱對應一個消費者組。盡管消息僅在主題（Topic）上存儲一次，但是用戶可以有不同的訂閱方式來消費這些消息：
- 消費者被組合在一起以消費消息，每個消費組是一個訂閱。
- 每個 Topic 可以有不同的消費組。
- 每組消費者都是對主題的一個訂閱。
- 每組消費者可以擁有自己不同的消費方式：獨占（Exclusive），故障切換（Failover）或共享（Share）。
Pulsar 通過這種模型，將隊列模型和流模型這兩種模型結合在了一起，提供了統一的 API 接口。這種模型，既不會影響消息系統的性能，也不會帶來額外的開銷，同時還為用戶提供了更多靈活性，方便用戶程序以最匹配模式來使用消息系統。
多種 MQ 協議兼容—輕松遷移傳統 MQ 服務
在 Pulsar 架構中，為了處理 Bookie 存儲消息和防止消息丟失等，基於 Managed Leger 實現了一套分布式的流程封裝。Pulsar Protocol Handler 處理 Pulsar 中生產者和消費者發送出來的 TCP 請求，將其轉化為可讀取狀態的操作。Pulsar 2.5 版本后，將 Protocol Handler 接口單獨脫離了出來，利用這個框架就可以單獨實現自定義協議的轉換，比如 Kafka、AMQP 等，可以幫助存量的 MQ 業務輕松遷移到 Pulsar。
Kafka Protocol Handler 目前是一個獨立的項目在維護— Kafka On Pulsar（簡稱KoP），由於公司內存量 Kafka 業務很多，數平 MQ 團隊針對 KoP 做了大量的優化工作，騰訊現在有其他團隊也在更深度參與KoP項目，詳情可以參考騰訊加盟：Kafka-on-Pulsar 項目迎來 2 位騰訊 Maintainer！
企業級多租戶特性—數據安全有保證
作為企業的消息中樞，Apache Pulsar 自誕生之日起就支持多租戶，因為該項目最初就是為了滿足 Yahoo 的嚴格需求，而當時市面上沒有任何可用的開源系統能夠提供多租戶功能。在 Pulsar 的設計中，租戶可以跨集群分布，每個租戶都可以有單獨的認證和授權機制；租戶也是存儲配額、消息 TTL 和隔離策略的管理單元。Pulsar 通過下列方式滿足了多租戶場景下的數據安全：
- 通過為每個租戶進行身份驗證、授權和 ACL（訪問控制列表）獲得所需安全性。
- 為每個租戶強制實施存儲配額。
- 以策略的方式定義所有隔離機制，策略可在運行過程中更改，借此降低運維成本並簡化管理工作。
跨地域復制—自帶跨機房冗災能力
在大型的分布式系統中，都會涉及到跨多個數據中心的需求。在對服務質量和災備要求更高的場景中，會規划將機房部署在地理位置分散的多個數據中心內。在此類多數據中心部署中，通常會使用跨地域復制機制提供額外的冗余，以防某個數據中心故障、自然侵害或其他事件導致服務無法正常運作。Apache Pulsar 在設計之初就加入了對 Yahoo 全球十多個機房的跨地域復制的需求。Apache Pulsar 的跨地域多機房互備特性是 Pulsar 企業級特性的重要組成部分，它在保證數據穩定可靠的同時，為用戶提供了便捷的操作和管理。
在上圖中，無論 Producer P1、P2 和 P3 在什么時候分別將消息發布給 Cluster A、Cluster B 和 Cluster C 中的 Topic T1，這些消息均會立刻復制到整個集群。一旦完成復制，Consumer C1 和 C2 即可從自己所在的集群消費這些消息。
Pulsar 的跨地域復制不僅應用在跨數據中心數據備份的場景，在 PowerFL 聯邦學習平台中跨地域復制的能力還被用來做通信服務使用。
雲原生支持—助力服務上雲
雲原生的原生即軟件設計之初就考慮到了將來會被運行在雲端的可能，從而在設計層面上就充分利用了雲資源的特點，典型的是分布式和彈性伸縮的能力。Pulsar 之所以說是雲原生的消息平台，核心就是它的架構設計能夠充分利用分布式的、能夠彈性伸縮的雲端資源。以 Pulsar on Kubernetes 為例，Bookie 是有狀態的節點，但是節點之間是對等的，可以采用 StatefulSet 來部署；而 Broker 作為無狀態的節點，直接使用 ReplicaSet 即可，每個 Pod 支持水平擴展。
目前公司已經有業務使用 Pulsar on Kubernetes，如果 bookie 使用 Local Storage Volume，對 Pulsar 的性能基本沒有影響。