消息隊列使用場景

消息隊列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，削峰填谷等問題。實現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。

• 解耦：多個服務(wù)監(jiān)聽、處理同一條消息，避免多次 rpc 調(diào)用。

• 異步消息：消息發(fā)布者不用等待消息處理的的結(jié)果。

• 削峰填谷：較大流量、寫入場景，為下游 I/O 服務(wù)抗流量。當然大流量下就需要使用其他方案了。

• 消息驅(qū)動框架：在事件總線中，服務(wù)通過監(jiān)聽事件消息驅(qū)動服務(wù)完成相應(yīng)動作。

消息隊列模式

點對點模式，不可重復(fù)消費

多個生產(chǎn)者可以向同一個消息隊列發(fā)送消息，一個消息在被一個消息者消費成功后，這條消息會被移除，其他消費者無法處理該消息。如果消費者處理一個消息失敗了，那么這條消息會重新被消費。

發(fā)布/訂閱模式

發(fā)布訂閱模式需要進行注冊、訂閱，根據(jù)注冊消費對應(yīng)的消息。多個生產(chǎn)者可以將消息寫到同一個 Topic 中，多種消息可以被同一個消費者消費。一個生產(chǎn)者生產(chǎn)的消息，同樣也可以被多個消費者消費，只要他們進行過消息訂閱。

選型參考

• 消息順序：發(fā)送到隊列的消息，消費時是否可以保證消費的順序；

• 伸縮：當消息隊列性能有問題，比如消費太慢，是否可以快速支持擴容；當消費隊列過多，浪費系統(tǒng)資源，是否可以支持縮容。

• 消息留存：消息消費成功后，是否還會繼續(xù)保留在消息隊列；

• 容錯性：當一條消息消費失敗后，是否有一些機制，保證這條消息一定能成功，比如異步第三方退款消息，需要保證這條消息消費掉，才能確定給用戶退款成功，所以必須保證這條消息消費成功的準確性；

• 消息可靠性：是否會存在丟消息的情況，比如有 A/B 兩個消息，最后只有 B 消息能消費，A 消息丟失；

• 消息時序：主要包括“消息存活時間”和“延遲消息”；

• 吞吐量：支持的最高并發(fā)數(shù)；

• 消息路由：根據(jù)路由規(guī)則，只訂閱匹配路由規(guī)則的消息，比如有 A/B 兩者規(guī)則的消息，消費者可以只訂閱 A 消息，B 消息不會消費。

Kafka

Kafka 是由 Apache 軟件基金會開發(fā)的一個開源流處理平臺，由 Scala 和 Java 編寫。該項目的目標是為處理實時數(shù)據(jù)提供一個統(tǒng)一、高吞吐、低延遲的平臺。其持久化層本質(zhì)上是一個“按照分布式事務(wù)日志架構(gòu)的大規(guī)模發(fā)布/訂閱消息隊列”，這使它作為企業(yè)級基礎(chǔ)設(shè)施來處理流式數(shù)據(jù)非常有價值。（維基百科）

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個人覺得比較好的學(xué)習書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實戰(zhàn)項目及代碼)? ? ? ?

基本術(shù)語

Producer：消息生產(chǎn)者。一般情況下，一條消息會被發(fā)送到特定的主題上。通常情況下，寫入的消息會通過輪詢將消息寫入各分區(qū)。生產(chǎn)者也可以通過設(shè)定消息 key 值將消息寫入指定分區(qū)。寫入分區(qū)的數(shù)據(jù)越均勻 Kafka 的性能才能更好發(fā)揮。

Topic：Topic 是個抽象的虛擬概念，一個集群可以有多個 Topic，作為一類消息的標識。一個生產(chǎn)者將消息發(fā)送到 topic，消費者通過訂閱 Topic 獲取分區(qū)消息。

Partition：Partition 是個物理概念，一個 Topic 對應(yīng)一個或多個 Partition。新消息會以追加的方式寫入分區(qū)里，在同一個 Partition 里消息是有序的。Kafka 通過分區(qū)，實現(xiàn)消息的冗余和伸縮性，以及支持物理上的并發(fā)讀、寫，大大提高了吞吐量。

Replicas：一個 Partition 有多個 Replicas 副本。這些副本保存在 broker，每個 broker 存儲著成百上千個不同主題和分區(qū)的副本，存儲的內(nèi)容分為兩種：master 副本，每個 Partition 都有一個 master 副本，所有內(nèi)容的寫入和消費都會經(jīng)過 master 副本；follower 副本不處理任何客戶端的請求，只同步 master 的內(nèi)容進行復(fù)制。如果 master 發(fā)生了異常，很快會有一個 follower 成為新的 master。

Consumer：消息讀取者。消費者訂閱主題，并按照一定順序讀取消息。Kafka 保證每個分區(qū)只能被一個消費者使用。

Offset：偏移量是一種元數(shù)據(jù)，是不斷遞增的整數(shù)。在消息寫入時 Kafka 會把它添加到消息里。在分區(qū)內(nèi)偏移量是唯一的。消費過程中，會將最后讀取的偏移量存儲在 Kafka 中，消費者關(guān)閉偏移量不會丟失，重啟會繼續(xù)從上次位置開始消費。

Broker：獨立的 Kafka 服務(wù)器。一個 Topic 有 N 個 Partition，一個集群有 N 個 Broker，那么每個 Broker 都會存儲一個這個 Topic 的 Partition。如果某 topic 有 N 個 partition，集群有(N+M)個 broker，那么其中有 N 個 broker 存儲該 topic 的一個 partition，剩下的 M 個 broker 不存儲該 topic 的 partition 數(shù)據(jù)。如果某 topic 有 N 個 partition，集群中 broker 數(shù)目少于 N 個，那么一個 broker 存儲該 topic 的一個或多個 partition。在實際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導(dǎo)致 Kafka 集群數(shù)據(jù)不均衡。

系統(tǒng)框架

第一個 topic 有兩個生產(chǎn)，新消息被寫入到 partition 1 或者 partition 2，兩個分區(qū)在 broker1、broker2 都有備份。有新消息寫入后，兩個 follower 分區(qū)會從兩個 master 分區(qū)同步變更。對應(yīng)的 consumer 會從兩個 master 分區(qū)根據(jù)現(xiàn)在 offset 獲取消息，并更新 offset。第二個 topic 只有一個生產(chǎn)者，同樣對應(yīng)兩個 partition，分散在 Kafka 集群的兩個 broker 上。有新消息寫入，兩個 follower 分區(qū)會同步 master 變更。兩個 Consumer 分別從不同的 master 分區(qū)獲取消息。

優(yōu)點

高吞吐量、低延遲：kafka 每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒；

可擴展性：kafka 集群支持熱擴展；

持久性、可靠性：消息被持久化到本地磁盤，并且支持數(shù)據(jù)備份防止數(shù)據(jù)丟失；

容錯性：允許集群中節(jié)點故障，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)；

高并發(fā)：支持數(shù)千個客戶端同時讀寫。

缺點

分區(qū)有序：僅在同一分區(qū)內(nèi)保證有序，無法實現(xiàn)全局有序；

無延時消息：消費順序是按照寫入時的順序，不支持延時消息

重復(fù)消費：消費系統(tǒng)宕機、重啟導(dǎo)致 offset 未提交；

Rebalance：Rebalance 的過程中 consumer group 下的所有消費者實例都會停止工作，等待 Rebalance 過程完成。

使用場景

日志收集：大量的日志消息先寫入 kafka，數(shù)據(jù)服務(wù)通過消費 kafka 消息將數(shù)據(jù)落地；

消息系統(tǒng)：解耦生產(chǎn)者和消費者、緩存消息等；

用戶活動跟蹤：kafka 經(jīng)常被用來記錄 web 用戶或者 app 用戶的各種活動，如瀏覽網(wǎng)頁、搜索、點擊等活動，這些活動信息被各個服務(wù)器發(fā)布到 kafka 的 topic 中，然后消費者通過訂閱這些 topic 來做實時的監(jiān)控分析，亦可保存到數(shù)據(jù)庫；

運營指標：記錄運營、監(jiān)控數(shù)據(jù)，包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報警和報告；

流式處理：比如 spark streaming。

RabbitMQ

RabbitMQ 是實現(xiàn)了高級消息隊列協(xié)議（AMQP）的開源消息代理軟件（亦稱面向消息的中間件（英語：Message-oriented middleware）。RabbitMQ 服務(wù)器是用 Erlang 語言編寫的，而群集和故障轉(zhuǎn)移是構(gòu)建在開放電信平臺框架上的。所有主要的編程語言均有與代理接口通訊的客戶端函式庫。（維基百科）

基本術(shù)語

Broker：接收客戶端鏈接實體，實現(xiàn) AMQP 消息隊列和路由功能；

Virtual Host：是一個虛擬概念，權(quán)限控制的最小單位。一個 Virtual Host 里包含多個 Exchange 和 Queue；

Exchange：接收消息生產(chǎn)者的消息并將消息轉(zhuǎn)發(fā)到隊列。發(fā)送消息時根據(jù)不同 ExchangeType 的決定路由規(guī)則，ExchangeType 常用的有：direct、fanout 和 topic 三種；

Message Queue：消息隊列，存儲為被消費的消息；

Message：由 Header 和 Body 組成，Header 是生產(chǎn)者添加的各種屬性，包含 Message 是否持久化、哪個 MessageQueue 接收、優(yōu)先級。Body 是具體的消息內(nèi)容；

Binding：Binding 連接起了 Exchange 和 Message Queue。在服務(wù)器運行時，會生成一張路由表，這張路由表上記錄著 MessageQueue 的條件和 BindingKey 值。當 Exchange 收到消息后，會解析消息中的 Header 得到 BindingKey，并根據(jù)路由表和 ExchangeType 將消息發(fā)送到對應(yīng)的 MessageQueue。最終的匹配模式是由 ExchangeType 決定；

Connection：在 Broker 和客戶端之間的 TCP 連接；

Channel：信道。Broker 和客戶端只有 tcp 連接是不能發(fā)送消息的，必須創(chuàng)建信道。AMQP 協(xié)議規(guī)定只有通過 Channel 才能執(zhí)行 AMQP 命令。一個 Connection 可以包含多個 Channel。之所以需要建立 Channel，是因為每個 TCP 連接都是很寶貴的。如果每個客戶端、每個線程都需要和 Broker 交互，都需要維護一個 TCP 連接的話是機器耗費資源的，一般建議共享 Connection。RabbitMQ 不建議客戶端線程之前共享 Channel，至少保證同一 Channel 發(fā)小消息是穿行的；

Command：AMQP 命令，客戶端通過 Command 來完成和 AMQP 服務(wù)器的交互。

系統(tǒng)框架

一條 Message 經(jīng)過信道到達對應(yīng)的 Exchange，Exchange 收到消息后解析出消息 Header 內(nèi)容，獲取消息 BindingKey 并根據(jù) Binding 和 ExchangeType 將消息轉(zhuǎn)發(fā)到對應(yīng)的 MessageQueue，最后通過 Connection 將消息傳送的客戶端。

ExchangeType

Direct：精確匹配

• 只有 RoutingKey 和 BindingKey 完全匹配的時候，消息隊列才可以獲取消息；

• Broker 默認提供一個 Exchange，類型是 Direct 名字是空字符串，綁定到所有的 Queue（這里通過 Queue 名字來區(qū)分）。

Fanout：訂閱、廣播

• 這個模式會將消息轉(zhuǎn)發(fā)到所有的路由的 Queue 中

Topic：通配符模式

• RoutingKey 為一個句點號“. ”分隔的字符串（將被句點號“. ”分隔開的每一段獨立的字符串稱為一個單詞），如“quick.orange.rabbit”。BindingKey 與 RoutingKey 一樣；

• Bindingkey 中的兩個特殊字符"#"和“_”用于模糊匹配，“#”用于匹配多個單次，“_”用來匹配單個單詞（包含零個）。

優(yōu)點

• 基于 AMQP 協(xié)議：除了 Qpid，RabbitMQ 是唯一一個實現(xiàn)了 AMQP 標準的消息服務(wù)器；

• 健壯、穩(wěn)定、易用；

• 社區(qū)活躍，文檔完善；

• 支持定時消息；

• 可插入的身份驗證，授權(quán)，支持 TLS 和 LDAP；

• 支持根據(jù)消息標識查詢消息，也支持根據(jù)消息內(nèi)容查詢消息。

缺點

• erlang 開發(fā)源碼難懂，不利于做二次開發(fā)和維護；

• 接口和協(xié)議復(fù)雜，學(xué)習和維護成本較高。

總結(jié)

• erlang 有并發(fā)優(yōu)勢，性能較好。雖然源碼復(fù)雜，但是社區(qū)活躍度高，可以解決開發(fā)中遇到的問題；

• 業(yè)務(wù)流量不大的話可以選擇功能比較完備的 RabbitMQ。

Pulsar

Apache Pulsar 是 Apache 軟件基金會頂級項目，是下一代云原生分布式消息流平臺，集消息、存儲、輕量化函數(shù)式計算為一體，采用計算與存儲分離架構(gòu)設(shè)計，支持多租戶、持久化存儲、多機房跨區(qū)域數(shù)據(jù)復(fù)制，具有強一致性、高吞吐、低延時及高可擴展性等流數(shù)據(jù)存儲特性，被看作是云原生時代實時消息流傳輸、存儲和計算最佳解決方案。Pulsar 是一個 pub-sub (發(fā)布-訂閱)模型的消息隊列系統(tǒng)。（百科）

基本術(shù)語

Property：代表租戶，每個 property 都可以代表一個團隊、一個功能、一個產(chǎn)品線。一個 property 可包含多個 namesapce，多租戶是一種資源隔離手段，可以提高資源利用率；

Namespace：Pulsar 的基本管理單元，在 namaspace 級別可設(shè)置權(quán)限、消息 TTL、Retention 策略等。一個 namaspace 里的所有 topic 都繼承相同的設(shè)置。命名空間分為兩種：本地命名空間，只在集群內(nèi)可見、全局命名空間對多個集群可見集群命名空間；

Producer：數(shù)據(jù)生產(chǎn)方，負責創(chuàng)建消息并將消息投遞到 Pulsar 中；

Consumer：數(shù)據(jù)消費方，連接到 Pulsar 接收消息并進行相應(yīng)的處理；

Broker：無狀態(tài) Proxy 服務(wù)，負責接收消息、傳遞消息、集群負載均衡等操作，它對 client 屏蔽了服務(wù)端讀寫流程的復(fù)雜性，是保證數(shù)據(jù)一致性與數(shù)據(jù)負載均衡的重要角色。Broker 不會持久化保存元數(shù)據(jù)?？梢詳U容但不能縮容；

BookKeeper：有狀態(tài)，負責持久化存儲消息。當集群擴容時，Pulsar 會在新增 BookKeeper 和 Segment（即 Bookeeper 的 Ledger），不需要像 kafka 一樣在擴容時進行 Rebalance。擴容結(jié)果是 Fragments 跨多個 Bookies 以帶狀分布，同一個 Ledger 的 Fragments 分布在多個 Bookie 上，導(dǎo)致讀取和寫入會在多個 Bookies 之間跳躍；

ZooKeeper：存儲 Pulsar 、 BookKeeper 的元數(shù)據(jù)，集群配置等信息，負責集群間的協(xié)調(diào)、服務(wù)發(fā)現(xiàn)等；

Topic：用作從 producer 到 consumer 傳輸消息。Pulsar 在 Topic 級別擁有一個 leader Broker，稱之為擁有 Topic 的所有權(quán)，針對該 Topic 所有的 R/W 都經(jīng)過該 Broker 完成。Topic 的 Ledger 和 Fragment 之間映射關(guān)系等元數(shù)據(jù)存儲在 Zookeeper 中，Pulsar Broker 需要實時跟蹤這些關(guān)系進行讀寫流程；

Ledger：即 Segment，Pulsar 底層數(shù)據(jù)以 Ledger 的形式存儲在 BookKeeper 上。是 Pulsar 刪除的最小單位；

Fragment?：每個 Ledger 由若干 Fragment 組成。

系統(tǒng)框架

上面框架圖分別演示了擴容、故障轉(zhuǎn)移兩種情況。擴容：因業(yè)務(wù)量增大擴容新增 Bookie N，后續(xù)寫入的數(shù)據(jù) segment x、segment y 寫入新增 Bookie 中，為保持均衡擴容結(jié)果如上圖綠色模塊所示。故障轉(zhuǎn)移：Bookie 2 的 segment 4 發(fā)生故障，Pulasr 的 Topic 會立馬從新選擇 Bookie 1 作為處理讀寫的服務(wù)。

Broker 是無狀態(tài)的服務(wù)，只服務(wù)數(shù)據(jù)計算不存儲，所以 Pulsar 可以認為是一種基于 Proxy 的分布式系統(tǒng)。

優(yōu)點

• 靈活擴容

• 無縫故障恢復(fù)

• 支持延時消息

• 內(nèi)置的復(fù)制功能，用于跨地域復(fù)制如災(zāi)備

• 支持兩種消費模型：流（獨享模式）、隊列（共享模式）

RocketMQ

RocketMQ 是一個分布式消息和流數(shù)據(jù)平臺，具有低延遲、高性能、高可靠性、萬億級容量和靈活的可擴展性。RocketMQ 是 2012 年阿里巴巴開源的第三代分布式消息中間件。（維基百科）

基本術(shù)語

Topic：一個 Topic 可以有 0 個、1 個、多個生產(chǎn)者向其發(fā)送消息，一個生產(chǎn)者也可以同時向不同的 Topic 發(fā)送消息。一個 Topic 也可以被 0 個、1 個、多個消費者訂閱；

Tag：消息二級類型，可以為用戶提供額外的靈活度，一條消息可以沒有 tag；

Producer：消息生產(chǎn)者；

Broker：存儲消息，以 Topic 為緯度輕量級的隊列；轉(zhuǎn)發(fā)消息，單個 Broker 節(jié)點與所有的 NameServer 節(jié)點保持長連接及心跳，會定時將 Topic 信息注冊到 NameServer；

Consumer：消息消費者，負責接收并消費消息；

MessageQueue：消息的物理管理單位，一個 Topic 可以有多個 Queue，Queue 的引入實現(xiàn)了水平擴展的能力；

NameServer：負責對原數(shù)據(jù)的管理，包括 Topic 和路由信息，每個 NameServer 之間是沒有通信的；

Group：一個組可以訂閱多個 Topic，ProducerGroup、ConsumerGroup 分別是一類生產(chǎn)者和一類消費者；

Offset：通過 Offset 訪問存儲單元，RocketMQ 中所有消息都是持久化的，且存儲單元定長。Offset 為 Java Long 類型，理論上 100 年內(nèi)不會溢出，所以認為 Message Queue 是無限長的數(shù)據(jù)，Offset 是下標；

Consumer：支持 PUSH 和 PULL 兩種消費模式，支持集群消費和廣播消費。

系統(tǒng)框架

優(yōu)點

支持發(fā)布/訂閱（Pub/Sub）和點對點（P2P）消息模型：

• 順序隊列：在一個隊列中可靠的先進先出（FIFO）和嚴格的順序傳遞；支持拉（pull）和推（push）兩種消息模式；

• 單一隊列百萬消息的堆積能力；

• 支持多種消息協(xié)議，如 JMS、MQTT 等；

• 分布式橫向擴展架構(gòu)；

• 滿足至少一次消息傳遞語義；

• 提供豐富的 Dashboard，包含配置、指標和監(jiān)控等；

• 支持的客戶端，目前是 java、c++及 golang

缺點

• 社區(qū)活躍度一般；

• 延時消息：開源版不支持任意時間精度，僅支持特定的 level。

使用場景

• ?為金融互聯(lián)網(wǎng)領(lǐng)域而生，對于可靠性要求很高的場景。

原文作者：極客重生