之前對消息隊列服務中間件進行了對比,具體可以參看《消息隊列選型》。
一般互聯網公司都使用消息隊列來實現系統解耦,提速,廣播,流量削峰等應用場景。
ZeroMQ,低延時、高性能特性,被應用於實時性要求高的系統解耦。
1、什麼是ZeroMQ:
據官方文檔介紹,ZeroMQ是一個可伸縮的分佈式或者高併發的異步網絡消息庫。不同於其他的服務,例如RabbitMQ等消息隊列服務,以一種可獨立運營的服務存在,ZeroMQ是一套高效的socket library,是對BSD socket進行的上層封裝。在傳統的BSD網絡開發模型中,採用的是socket與socket之間的消息傳輸,即1:1的消息傳輸鏈接,在ZeroMQ中是node與node之間的消息傳輸,node之間存在多條數據鏈接,即N: M的消息傳輸鏈接。ZeroMQ在底層實現了關於進程通信、網絡通信、線程通信等各種細節的封裝,讓開發者更多的關注應用層的開發。
簡單來說,ZeroMQ是對Socket進行了封裝的lib庫,在使用的時候不用搭建隊列環境,只需要引入lib包,然後在生產方和消費方調用API就可以。
2、 ZeroMQ的主要特點
I/O操作屬於後臺異步操作,同時採用的是無鎖數據結構,提高應用的高併發性;
存在斷線重連機制,Server、Client啟動的無序性;
l消息的消費者處理速度比較慢時,會導致消息的生產者阻塞或者,可以在使用過程中進行設置;
l消息內容可以使用任何的格式,框架本身不對消息格式做任何的限制;
3、ZeroMQ的基本使用模型
ZeroMQ提供了三個經常使用的基本模型,分別為:Request—Reply、Publish—Subscribe、Parallel PipeLine三種工作模型,通過這三種工作模型可以衍生出很多的使用模型。下面分別對這三種模型進行簡單的介紹:
1)Request—Reply模型
Request—Reply模型與傳統的BSD網絡開發模型類似,也就是俗稱的“應答模型”,具體模型如下圖所示
Server代碼如下:
Client代碼如下:
在使用該模型過程中存在幾個注意事項:
必須採用嚴格的發送——接受的順序,否則會導致此次的發送或者接受失敗;
區別傳統的BSD開發,Server先啟動,Client再啟動的流程,在ZeroMQ中Server與Client啟動順序沒有要求;
發送頻率受端口鏈接數限制,如果超過限制會導致jvm停止
2)Pub-Sub模型
Pub-Sub模型是一個服務器將消息發送給多個客戶端,類似於群發短信的業務場景
Pub側代碼如下:
Sub側代碼如下:
Pub-Sub模型使用過程中的注意事項為:
需要在服務中顯式設置服務是PUB還是SUB,即在服務中需要明確在系統中扮演的角色;
扮演PUB角色的服務,不可以調用zmq_recv,扮演SUB角色的服務,不可以調用zmq_send角色,否則會導致服務出錯;
PUB允許存在多個SUB服務,SUB服務也允許從多個PUB中訂閱數據;
使用這種模型最適合的場景為:SUB在啟動時,不關心PUB已經發送的數據內容;
PUB在沒有接收到SUB連接請求的情況下,PUB會丟棄全部的數據;
如果SUB的處理效率比較慢,PUB側會維持消息隊列;
根據設置的過濾條件的不同,過濾條件生效的位置不同;
3)Parallel PipeLine
Server端作為Push端,而Client端作為Pull端,如果有多個Client端同時連接到Server端,則Server端會在內部做一個負載均衡,採用平均分配的算法,將所有消息均衡發佈到Client端上。如果有多個Server端同時連接到Client端,這裡Push與Pull之間的對應關係是多個Push角色對應一個Pull角色,在ZeroMQ中,給這種結構取的名叫做公平隊列,這裡也就是說將Pull角色理解為一個隊列,各個Push角色不斷的向這個隊列中發送數據。與發佈訂閱模型相比,推拉模型在沒有消費者的情況下,發佈的消息不會被消耗掉;在消費者能力不夠的情況下,能夠提供多消費者並行消費解決方案。該模型主要用於多任務並行處理。
Push端代碼實現:
Pull端代碼
注意事項:
PULL端可以過濾接收到的消息,在設置connect參數的時候在端口後邊添加過濾字符串。
閱讀更多 HelloWorld應用 的文章