消息隊列規范及實現


一、消息中間件

消息中間件即Message-oriented middleware(MOM),消息中間件利用高效可靠的消息傳遞機制進行平台無關的數據交流,並基於數據通信來進行分布式系統的集成。
通過提供消息傳遞和消息排隊模型,消息中間件可以在分布式環境下擴展進程間的通信。
消息中間件可以即支持同步方式,又支持異步方式。
異步中間件比同步中間件具有更強的容錯性,在系統故障時可以保證消息的正常傳輸。異步中間件技術又分為兩類:廣播方式和發布/訂閱方式。
消息中間件應用主要有兩個優點:異步和解耦。

1.AMQP規范

AMQP 是 Advanced Message Queuing Protocol,即高級消息隊列協議。AMQP不是一個具體的消息隊列實現,而 是一個標准化的消息中間件協議。目標是讓不同語言,不同系統的應用互相通信,並提供一個簡單統一的模型和編程接口。
目前主流的ActiveMQ和RabbitMQ都支持AMQP協議。

AMQP相關的角色和職責

Producer 消息生產者

一個給exchange發送消息的程序,發送方式大致是:它首先創建一個空消息,然后填上內容、路由KEY,最后發送給exchange

Routing Key 消息特征

一個字符串,exchange用之來決定應該該消息投遞給哪個queue。(開始時queue已向exchange綁定它所關心消息的routingKey)

Exchange 交換器

接收來自producers的消息,並根據該消息的routingKey,將該消息投遞到正確的queues

Binding 綁定操作

前期將queue所想要的消息特征告訴exchange。Exchange以后收到消息,就按照這個規則來投遞

Queue 消息容器
在MQ server(實現為broker方式)里面的queue,持有Consumer想要的消息

Consumer 消息接收者
從MQ server得到想要的消息,它負責創建、主動訂閱、共享、使用、破壞queue和binding

2.JMS規范

JMS是Java平台的一部分,是一種應用於異步消息傳遞的標准API,JMS可以允許不同應用、不同模塊之間實現可靠、異步數據通信。

在JMS中,支持兩種消息模型,點對點(Point-to-point)和發布-訂閱(Publish and subscribe)
這兩種模式分別對應於JMS中的兩種消息目標(Message Destination):隊列及主題(queue/topic)

在點對點模型中,每個消息都有一個發送者和一個接收者,消息中介(broker)收到發送者的消息,會將消息放入隊列中,而接收者請求並接收隊列中的一條消息后,這條消息就會從隊列中刪除。
消息隊列中的每條消息只能投遞給一個接收者,但並不意味着只能使用一個接收者從隊列中取消息,根據業務需要,可以使用多個接收者同時從隊列中請求消息,分擔處理壓力。
但是需要注意的是,單個接收者收到的消息是按照發送順序的,多個接收者因為多線程的關系,並不能保證收到的消息一定是原序的。

在發布-訂閱模式中,消息會發送給一個主題,但是與點對點模式不同的是消息不再只被投遞給一個接收者,而是所有此主題的訂閱者都會收到該消息。

二、JMS規范實現

JMS即Java消息服務(Java Message Service),JMS是一個基於Java平台面向消息中間件(MOM)的API,用於在兩個應用程序之間,
或分布式系統中發送消息,進行異步通信。
Java消息服務是一個與具體平台無關的API,絕大多數MOM提供商都對JMS提供支持。
JMS是類似於JDBC(Java Database Connectivity),並不局限於某個具體消息中間件,
JDBC 是可以用來訪問許多不同關系數據庫的 API,
而 JMS 則提供同樣與中間件無關的訪問方法,以訪問消息收發服務。

1.JMS對象模型

ConnectionFactory:
連接工廠,JMS 用它創建連接Connection,一般設為單例模式,
一旦創建,就一直運行在應用容器內,客戶端使用JNDI查找連接工廠,然后利用連接工廠創建一個JMS連接。

Connection:
JMS連接表示JMS客戶端和服務器端之間的一個活動的連接,是由客戶端通過調用連接工廠的方法建立的。

Session:
JMS會話表示JMS客戶與JMS服務器之間的會話狀態。JMS會話建立在JMS連接上,表示客戶與服務器之間的一個會話線程。

Destination:
消息的目的,包括隊列(PTP),主題(Pub/Sub)。

Message Producer和Message Consumer:
生產者和消費者對象由Session對象創建,用於發送和接收消息。

Message:
JMS 消息由以下幾部分組成:消息頭,屬性,消息體。
消息頭(header):JMS消息頭包含了許多字段,它們是消息發送后由JMS提供者或消息發送者產生,用來表示消息、設置優先權和失效時間等等,並且為消息確定路由Routing。
屬性(property):由消息發送者產生,用來添加刪除消息頭以外的附加信息。
消息體(body):由消息發送者產生,JMS中定義了5種消息體:ByteMessage、MapMessage、ObjectMessage、StreamMessage和TextMessage。

2.兩種消息傳遞模型

(1)點對點模型(Point-to-Point)
點對點模型用於消息生產者和消息消費者之間點到點的通信。消息生產者將消息發動到由某個名字標識的特定消費者。這個名字實際上對應於消息服務中的一個隊列(Queue),在消息傳動給消費者之前它被存儲在這個隊列中。隊列可以是持久的,以保證在消息服務出現故障時仍然能夠傳遞消息。

(2)發布-訂閱模型(Publish/Subscribe)
發布-訂閱模型用稱為主題(topic)的內容分層結構代替了PTP模型中的惟一目的地,
發送應用程序發布自己的消息,指出消息描述的是有關分層結構中的一個主題的信息。希望接收這些消息的應用程序訂閱了這個主題。訂閱包含子主題的分層結構中的主題的訂閱者可以接收該主題和其子主題發表的所有消息

三、消息隊列的主要開源實現

  • ActiveMQ

ActiveMQ 是Apache出品,目前非常流行的開源消息中間件。ActiveMQ 支持JMS規范,同樣也支持AMQP協議。
在下面的博客里,將會較深入的學習ActiveMQ的設計和應用。

  • RabbitMQ

RabbitMQ 是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現,開發語言是以高性能、健壯以及可伸縮性出名的 Erlang 。

  • RocketMQ

RocketMQ 是阿里的一款分布式、隊列模型的消息中間件。
項目地址 https://github.com/alibaba/RocketMQ
軟件文檔 https://github.com/alibaba/RocketMQ/wiki

 

  • 三種消息隊列的比較 

 ActiveMQ  

優點:成熟的產品,已經在很多公司得到應用(非大規模場景)。有較多的文檔。 各種協議支持較好,有多重語言的成熟的客戶端;

缺點:根據其他用戶反饋,會出莫名其妙的問題,會丟失消息。其重心放到activemq6.0產品—apollo上去了,目前社區不活躍,且對 5.x 維護

較少;Activemq 不適合用於上千個隊列的應用場景

 

RabbitMQ 

優點:由於erlang語言的特性, mq性能較好;管理界面較豐富,在互聯網公司也有較大規模的應用;支持 amqp 系誒,有多中語言且支持amqp 的客戶端可用

缺點:erlang語言難度較大。集群不支持動態擴展。

 

RocketMq

優點:模型簡單,接口易用(JMS的接口很多場合並不太實用)。 在阿里大規模應用。 目前支付寶中的余額寶等新興產品均使用rocketmq。 

集群規模大概在50 台左右,單日處理消息上百億;性能非常好,可以大量堆積消息在broker 中;支持多種消費,包括集群消費、廣播消費等。 開發度較活躍,版本更新很快。

缺點:產品較新,文檔比較缺乏。沒有在 mq核心中去實現JMS 等接口,對已有系統而言不能兼容。阿里內部還有一套未開源的 MQ API,這一層 API可以將上層應用和下層 MQ 的實現解耦。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM