ZeroMQ號稱是“史上最快的消息隊列”，基於c語言開發的，實時流處理sorm的task之間的通信就是用的zeroMQ。
引用官方說法，“ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是“成爲標準網絡協議棧的一部分，之後進入Linux內核”。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的“傳統”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網絡應用程序極爲簡單和有趣。” 確實，它跟RabbitMQ，ActiveMQ之類有着相當本質的區別，ZeroMQ根本就不是一個消息隊列服務器，更像是一組底層網絡通訊庫，對原有的Socket API加上一層封裝，是我們操作更簡便。使用時只需要引入相應的jar包即可。
ZeroMQ與其他MQ類似，也實現了3中最基本的工作模式：發佈-訂閱，請求-應答，管道.
ZeroMQ特點
1.嵌入式消息組件
與rabbitMQ，ActiveMQ有很大的不同，如果說rabbitMQ已經近乎是一個小型操作系統，那麼ZeroMQ就像是一個嵌入在操作系統內的一個組件，說白了ZeroMQ就是一組jar包，直接嵌入到項目中就可以運行，它不需要一臺獨立的服務器來承載整個消息系統。
ZeroMQ關注的不是消息的可靠送達，而是着眼於端到端的發送，接收…它希望的是儘快完成任務，而不介意部分消息的丟失。
但這也並不是說他完全沒有持久化的功能，ZeroMQ是具有一定的本地持久化的功能的，但是能保存的數據量比較有限，而且是暫存於內存中的。
2. 高的離譜的吞吐量
這是網上找到的一張關於MQ的性能分析的圖表
顯示的是每秒鐘發送和接受的消息數。整個過程共產生1百萬條1K的消息，測試環境爲Windows Vista。從測試數據可以看出，ZeroMQ的性能遠遠高於其它3個MQ。或者說ZeroMQ與其他3各MQ根本就不再一個量級上比較合適。
至於這樣的原因跟ZeroMQ的定位，以及對消息的處理方式有很大關聯。
ZeroMQ對於消息的處理可以說除卻請求-應答模式之外，基本就是不關係消息是否丟失，它只管發送。
ZeroMQ的定位，它的創始人一直在其社區表示，團隊將立志於把ZeroMQ融入到Linux內核中去。
基於以上兩點，高效的處理速度就成了它必不可少的特點之一。
3.多核下的線程綁定
傳統的多線程併發模式一般會採用鎖，臨界區，信號量等技術來控制，而ZeroMQ給出的建議是：在創建IO時不要超出CPU核數。
當我們創建一個上下文時都會有這麼一句代碼“Context context = ZMQ.context(1);”這裏就指定了IO線程數。通常來說一個線程足矣。但是如果希望創建多個IO線程，最好不要超出CPU核數，因爲此時ZeroMQ會將工作線程其實就是那個Poller綁定到每一個核，免除了線程上下文切換帶來的開銷。
4.與其它MQ相比
關於ZeroMQ與其他幾個MQ之間的比較，我們在TPS，併發性，持久化，技術點以及擴展性這幾個方面進行展開。
1.TPS
之前提過，這裏在說一下。
顯示的是每秒鐘發送和接受的消息數。整個過程共產生1百萬條1K的消息，測試環境爲Windows Vista。
明顯的ZeroMQ最好，其餘三者差不多。
2.持久化消息比較
ZeroMq原生是不支持的，僅支持相當有限的本地緩存，如需要消息持久化需要自己進行擴展。
ActiveMq和rabbitMq都支持。
3.併發性
雖然ZeroMQ在高併發環境下不會出問題，但是有可能會導致本地的緩存區被塞滿而導致消息丟失的情況。所以不推薦在併發量較高的情境下使用ZeroMQ.
查了下資料發現，ActiveMQ在發送到queue的消息併發較多時，消費端只能接收一部分，比如100條消息在較短的時間內發入，總有10來條接收不到，存放在服務器上，而且這些消息一直不能主動發送出來，後面繼續進入的消息都能正常處理，最終只有重新啓動服務消費端才能接收到那部分剩下的消息。
而RabbitMQ，從實現語言來看，它是併發性最好的，原因是它的實現語言是天生具備高併發高可用的erlang語言。
4.技術點以及擴展性
ok，首先就擴展性而言，那毫無疑問的是ZeroMQ最強，其餘其中MQ都已經是成形的產品，已經是一款應用程序了。而ZeroMQ說白了就是一組庫函數。基於這種情況，我們可以按自己的需要實現IPollEvent以及ZObject來開發適合自己的Socket組件，至於它對於消息持久化的不支持，只是原生不支持，因爲它的定位不是吃保證可靠的消息傳輸。所以在可靠性這部分我們完全可以按自己的需求進行擴展。一組lib的擴展度明顯是寬於產品級的rabbitMQ之類的產品。
技術上雖然ZeroMQ立志於成爲Linux內核的消息組件，但是不得不說它的開源社區活躍度是遠遠不及RabbitMQ或者ActiveMQ。或許是處於它的可靠性考慮，它的應用場景比較受限制。
可靠性上雖然ActiveMQ也具備，只是性能上相比於RabbitMQ還是有一定差距，所以大部分的MQ選型都是RabbitMQ。