大型網站架構系列：訊息佇列（二）

本次分享大綱

1. 訊息佇列概述（見第一篇：大型網站架構系列：分散式訊息佇列（一））
2. 訊息佇列應用場景（見第一篇：大型網站架構系列：分散式訊息佇列（一））
3. 訊息中介軟體示例（見第一篇：大型網站架構系列：分散式訊息佇列（一））
4. JMS訊息服務
5. 常用訊息佇列
6. 參考（推薦）資料
7. 本次分享總結

四、JMS訊息服務

講訊息佇列就不得不提JMS 。JMS（JAVA Message Service,java訊息服務）API是一個訊息服務的標準/規範，允許應用程式元件基於JavaEE平臺建立、傳送、接收和讀取訊息。它使分散式通訊耦合度更低，訊息服務更加可靠以及非同步性。

在EJB架構中，有訊息bean可以無縫的與JM訊息服務整合。在J2EE架構模式中，有訊息服務者模式，用於實現訊息與應用直接的解耦。

4.1訊息模型

在JMS標準中，有兩種訊息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

4.1.1 P2P模式

 

P2P模式包含三個角色：訊息佇列（Queue），傳送者(Sender)，接收者(Receiver)。每個訊息都被髮送到一個特定的佇列，接收者從佇列中獲取訊息。佇列保留著訊息，直到他們被消費或超時。

 

P2P的特點

• 每個訊息只有一個消費者（Consumer）(即一旦被消費，訊息就不再在訊息佇列中)
• 傳送者和接收者之間在時間上沒有依賴性，也就是說當傳送者傳送了訊息之後，不管接收者有沒有正在執行，它不會影響到訊息被髮送到佇列
• 接收者在成功接收訊息之後需向佇列應答成功

 

如果希望傳送的每個訊息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）

4.1.2 Pub/sub模式

 

包含三個角色主題（Topic），釋出者（Publisher），訂閱者（Subscriber） 。多個釋出者將訊息傳送到Topic,系統將這些訊息傳遞給多個訂閱者。

Pub/Sub的特點

• 每個訊息可以有多個消費者
• 釋出者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱者之後，才能消費釋出者的訊息。
• 為了消費訊息，訂閱者必須保持執行的狀態。

 

為了緩和這樣嚴格的時間相關性，JMS允許訂閱者建立一個可持久化的訂閱。這樣，即使訂閱者沒有被啟用（執行），它也能接收到釋出者的訊息。

如果希望傳送的訊息可以不被做任何處理、或者只被一個訊息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。

4.2訊息消費

在JMS中，訊息的產生和消費都是非同步的。對於消費來說，JMS的訊息者可以通過兩種方式來消費訊息。

（1）同步

訂閱者或接收者通過receive方法來接收訊息，receive方法在接收到訊息之前（或超時之前）將一直阻塞；

（2）非同步

訂閱者或接收者可以註冊為一個訊息監聽器。當訊息到達之後，系統自動呼叫監聽器的onMessage方法。

 

JNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查詢和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連線建立所必須的資訊。

JNDI在JMS中起到查詢和訪問傳送目標或訊息來源的作用。（架構KKQ：466097527，歡迎加入）

4.3JMS程式設計模型

(1) ConnectionFactory

建立Connection物件的工廠，針對兩種不同的jms訊息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查詢ConnectionFactory物件。

(2) Destination

Destination的意思是訊息生產者的訊息傳送目標或者說訊息消費者的訊息來源。對於訊息生產者來說，它的Destination是某個佇列（Queue）或某個主題（Topic）;對於訊息消費者來說，它的Destination也是某個佇列或主題（即訊息來源）。

所以，Destination實際上就是兩種型別的物件：Queue、Topic可以通過JNDI來查詢Destination。

(3) Connection

Connection表示在客戶端和JMS系統之間建立的連結（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種型別：QueueConnection和TopicConnection。

(4) Session

Session是操作訊息的介面。可以通過session建立生產者、消費者、訊息等。Session提供了事務的功能。當需要使用session傳送/接收多個訊息時，可以將這些傳送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。

(5) 訊息的生產者

訊息生產者由Session建立，並用於將訊息傳送到Destination。同樣，訊息生產者分兩種型別：QueueSender和TopicPublisher。可以呼叫訊息生產者的方法（send或publish方法）傳送訊息。

(6) 訊息消費者

訊息消費者由Session建立，用於接收被髮送到Destination的訊息。兩種型別：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來建立。當然，也可以session的creatDurableSubscriber方法來建立持久化的訂閱者。

(7) MessageListener

訊息監聽器。如果註冊了訊息監聽器，一旦訊息到達，將自動呼叫監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。

 

深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，訊息中介軟體也是大型分散式系統必須的元件。本次分享主要做全域性性介紹，具體的深入需要大家學習，實踐，總結，領會。

五、常用訊息佇列

一般商用的容器，比如WebLogic，JBoss，都支援JMS標準，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的訊息中介軟體。本部分內容介紹常用的訊息中介軟體（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。

5.1 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。

ActiveMQ特性如下：

⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP

⒉ 完全支援JMS1.1和J2EE 1.4規範 （持久化，XA訊息，事務)

⒊ 對Spring的支援，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支援Spring2.0的特性

⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何相容J2EE 1.4 商業伺服器上

⒌ 支援多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

⒍ 支援通過JDBC和journal提供高速的訊息持久化

⒎ 從設計上保證了高效能的叢集，客戶端-伺服器，點對點

⒏ 支援Ajax

⒐ 支援與Axis的整合

⒑ 可以很容易得呼叫內嵌JMS provider，進行測試

5.2 RabbitMQ

RabbitMQ是流行的開源訊息佇列系統，用erlang語言開發。RabbitMQ是AMQP（高階訊息佇列協議）的標準實現。支援多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支援AJAX，持久化。用於在分散式系統中儲存轉發訊息，在易用性、擴充套件性、高可用性等方面表現不俗。

結構圖如下：（架構KKQ：466097527，歡迎加入）

幾個重要概念：

Broker：簡單來說就是訊息佇列伺服器實體。

　　Exchange：訊息交換機，它指定訊息按什麼規則，路由到哪個佇列。

　　Queue：訊息佇列載體，每個訊息都會被投入到一個或多個佇列。

　　Binding：繫結，它的作用就是把exchange和queue按照路由規則繫結起來。

　　Routing Key：路由關鍵字，exchange根據這個關鍵字進行訊息投遞。

　　vhost：虛擬主機，一個broker裡可以開設多個vhost，用作不同使用者的許可權分離。

　　producer：訊息生產者，就是投遞訊息的程式。

　　consumer：訊息消費者，就是接受訊息的程式。

　　channel：訊息通道，在客戶端的每個連線裡，可建立多個channel，每個channel代表一個會話任務。

訊息佇列的使用過程，如下：

（1）客戶端連線到訊息佇列伺服器，開啟一個channel。

（2）客戶端宣告一個exchange，並設定相關屬性。

（3）客戶端宣告一個queue，並設定相關屬性。

（4）客戶端使用routing key，在exchange和queue之間建立好繫結關係。

（5）客戶端投遞訊息到exchange。

exchange接收到訊息後，就根據訊息的key和已經設定的binding，進行訊息路由，將訊息投遞到一個或多個佇列裡。

5.3 ZeroMQ

號稱史上最快的訊息佇列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關係），而ZMQ卻是可以N：M 的關係，人們對BSD套接字的瞭解較多的是點對點的連線，點對點連線需要顯式地建立連線、銷燬連線、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ遮蔽了這些細節，讓你的網路程式設計更為簡單。ZMQ用於node與node間的通訊，node可以是主機或者是程式。

引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket程式設計更加簡單、簡潔和效能更高。是一個訊息處理佇列庫，可在多個執行緒、核心和主機盒之間彈性伸縮。ZMQ的明確目標是“成為標準網路協議棧的一部分，之後進入Linux核心”。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的“傳統”BSD套接字之上的一 層封裝。ZMQ讓編寫高效能網路應用程式極為簡單和有趣。”

特點是：

• 高效能，非持久化；
• 跨平臺：支援Linux、Windows、OS X等。
• 多語言支援； C、C++、Java、.NET、Python等30多種開發語言。
• 可單獨部署或整合到應用中使用；
• 可作為Socket通訊庫使用。

與RabbitMQ相比，ZMQ並不像是一個傳統意義上的訊息佇列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、程式通訊和執行緒通訊抽象為統一的API介面。支援“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三種基本模型和擴充套件模型。

 

ZeroMQ高效能設計要點：

1、無鎖的佇列模型

   對於跨執行緒間的互動（使用者端和session）之間的資料交換通道pipe，採用無鎖的佇列演算法CAS；在pipe兩端註冊有非同步事件，在讀或者寫訊息到pipe的時，會自動觸發讀寫事件。

2、批量處理的演算法

   對於傳統的訊息處理，每個訊息在傳送和接收的時候，都需要系統的呼叫，這樣對於大量的訊息，系統的開銷比較大，zeroMQ對於批量的訊息，進行了適應性的優化，可以批量的接收和傳送訊息。

3、多核下的執行緒繫結，無須CPU切換

   區別於傳統的多執行緒併發模式，訊號量或者臨界區， zeroMQ充分利用多核的優勢，每個核繫結執行一個工作者執行緒，避免多執行緒之間的CPU切換開銷。

5.4 Kafka

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。 這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理，也是為了通過叢集機來提供實時的消費。

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，有如下特性：

• 通過O(1)的磁碟資料結構提供訊息的持久化，這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。（檔案追加的方式寫入資料，過期的資料定期刪除）
• 高吞吐量：即使是非常普通的硬體Kafka也可以支援每秒數百萬的訊息。
• 支援通過Kafka伺服器和消費機叢集來分割槽訊息。
• 支援Hadoop並行資料載入。

 

Kafka相關概念

• Broker

Kafka叢集包含一個或多個伺服器，這種伺服器被稱為broker[5]

• Topic

每條釋出到Kafka叢集的訊息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的訊息分開儲存，邏輯上一個Topic的訊息雖然儲存於一個或多個broker上但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處）

• Partition

Parition是物理上的概念，每個Topic包含一個或多個Partition.

• Producer

負責釋出訊息到Kafka broker

• Consumer

訊息消費者，向Kafka broker讀取訊息的客戶端。

• Consumer Group

每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於預設的group）。

 

一般應用在大資料日誌處理或對實時性（少量延遲），可靠性（少量丟資料）要求稍低的場景使用。

六、參考資料

以下是本次分享參考的資料和推薦大家參考的資料。

 

參考資料（可參考資料）：

（1）Jms

http://blog.sina.com.cn/s/blog_3fba24680100r777.html

http://blog.csdn.net/jiuqiyuliang/article/details/46701559（深入淺出JMS(一)--JMS基本概念）

（2）RabbitMQ

http://baike.baidu.com/link?url=s2cU-QgOsXan7j0AM5qxxlmruz6WEeBQXX-Bbk0O3F5jt9Qts2uYQARxQxl7CBT2SO2NF2VkzX_XZLqU-CTaPa

http://blog.csdn.net/sun305355024sun/article/details/41913105

（3）Zero MQ

http://www.searchtb.com/2012/08/zeromq-primer.html

http://blog.csdn.net/yangbutao/article/details/8498790

http://wenku.baidu.com/link?url=yYoiZ_pYPCuUxEsGQvMMleY08bcptZvwF3IMHo2W1i-ti66YXXPpLLJBGXboddwgGBnOehHiUdslFhtz7RGZYkrtMQQ02DV5sv9JFF4LZnK

（4）Kafka

http://baike.baidu.com/link?url=qQXyqvPQ1MVrw9WkOGSGEfSX1NHy4unsgc4ezzJwU94SrPuVnrKf2tbm4SllVaN3ArGGxV_N5hw8JTT2-lw4QK

http://www.infoq.com/cn/articles/apache-kafka/

http://www.mincoder.com/article/3942.shtml

已分享的電子資料（在群檔案中）

（1）Active MQ

 

（2）Kafka

 

（3）Notify

 

七、本次分享總結

以上是本週的分享，主要講解了訊息佇列概述，常用訊息佇列應用場景（非同步處理，應用解耦，流量削鋒，日誌處理和訊息通訊），JMS Java訊息服務，以及目前流行的幾款訊息佇列介紹。最後演示了兩個使用訊息中介軟體的架構。

因為時間關係，有些講解的不細緻，大家可以問下度娘/Google，希望本次分享對大家有幫助。

本次是春節前最後一次分享，我們的分享年後會繼續，明年會繼續《大型網站架構系列》，並會增加《一步一步學架構系列》。具體時間和分享內容會以QQ群公告的方式通知大家。感謝大家的關注。