之前對消息隊列服務中間件進行了對比，具體可以參看《消息隊列選型》。
一般互聯網公司都使用消息隊列來實現系統解耦，提速，廣播，流量削峰等應用場景。
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應用 的文章
