而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.
Procer
負責發布消息到Kafka broker
Consumer
消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬于一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬于默認的group）。
一般應用在大數據日志處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。
大數據技術的體系龐大且復雜，基礎的技術包含數據的采集、數據預處理、分布式存儲、數據庫、數據倉庫、機器學習、并行計算、可視化等。
1、數據采集與預處理：FlumeNG實時日志收集系統，支持在日志系統中定制各類數據發送方，用于收集數據；Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。
2、數據存儲：Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用于數據存儲。HBase，是一個分布式的、面向列的開源數據庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL數據庫。
3、數據清洗：MapRece作為Hadoop的查詢引擎，用于大規模數據集的并行計算。
4、數據查詢分析：Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張數據庫表，并提供HQL(HiveSQL)查詢功能。Spark啟用了內存分布數據集，除了能夠提供交互式查詢外，它還可以優化迭代工作負載。
5、數據可視化：對接一些BI平臺，將分析得到的數據進行可視化，用于指導決策服務。
1、有效期：限時活動、拼團。。。
2、超時處理：取消超時未支付訂單、超時自動確認收貨。。。
4、重試：網絡異常重試、打車派單、依賴條件未滿足重試。。。
5、定時任務：智能設備定時啟動。。。
1、RabbitMQ
1）簡介：基于AMQP協議，使用Erlang編寫，實現了一個Broker框架
a、Broker：接收和分發消息的代理服務器
b、Virtual Host：虛擬主機之間相互隔離，可理解為一個虛擬主機對應一個消息服務
c、Exchange：交換機，消息發送到指定虛擬機的交換機上
d、Binding：交換機與隊列綁定，并通過路由策略和routingKey將消息投遞到一個或多個隊列中
e、Queue：存放消息的隊列，FIFO，可持久化
f、Channel：信道，消費者通過信道消費消息，一個TCP連接上可同時創建成百上千個信道，作為消息隔離
2）延遲隊列實現：RabbitMQ的延遲隊列基于消息的存活時間TTL（Time To Live）和死信交換機DLE（Dead Letter Exchanges）實現
a、TTL：RabbitMQ支持對隊列和消息各自設置存活時間，取二者中較小的值，即隊列無消費者連接或消息在隊列中一直未被消費的過期時間
b、DLE：過期的消息通過綁定的死信交換機，路由到指定的死信隊列，消費者實際上消費的是死信隊列上的消息
3）缺點：
a、配置麻煩，額外增加一個死信交換機和一個死信隊列的配置
b、脆弱性，配置錯誤或者生產者消費者連接的隊列錯誤都有可能造成延遲失效
2、RocketMQ
1）簡介：來源于阿里，目前為Apache頂級開源項目，使用Java編寫，基于長輪詢的拉取方式，支持事務消息，并解決了順序消息和海量堆積的問題
a、Broker：存放Topic并根據讀取Procer的提交日志，將邏輯上的一個Topic分多個Queue存儲，每個Queue上存儲消息在提交日志上的位置
b、Name Server：無狀態的節點，維護Topic與Broker的對應關系以及Broker的主從關系
2）延遲隊列實現：RocketMQ發送延時消息時先把消息按照延遲時間段發送到指定的隊列中(rocketmq把每種延遲時間段的消息都存放到同一個隊列中)，然后通過一個定時器進行輪訓這些隊列，查看消息是否到期，如果到期就把這個消息發送到指定topic的隊列中
3）缺點：延遲時間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）
3、Kafka
1）簡介：來源于Linkedin，目前為Apache頂級開源項目，使用Scala和Java編寫，基于zookeeper協調的分布式、流處理的日志系統，升級版為Jafka
2）延遲隊列實現：Kafka支持延時生產、延時拉取、延時刪除等，其基于時間輪和JDK的DelayQueue實現
a、時間輪(TimingWheel)：是一個存儲定時任務的環形隊列，底層采用數組實現，數組中的每個元素可以存放一個定時任務列表
b、定時任務列表(TimerTaskList)：是一個環形的雙向鏈表，鏈表中的每一項表示的都是定時任務項
c、定時任務項(TimerTaskEntry)：封裝了真正的定時任務TimerTask
d、層級時間輪：當任務的到期時間超過了當前時間輪所表示的時間范圍時，就會嘗試添加到上層時間輪中，類似于鐘表就是一個三級時間輪
e、JDK DelayQueue：存儲TimerTaskList，并根據其expiration來推進時間輪的時間，每推進一次除執行相應任務列表外，層級時間輪也會進行相應調整
3）缺點：
a、延遲精度取決于時間格設置
b、延遲任務除由超時觸發還可能被外部事件觸發而執行
4、ActiveMQ
1）簡介：基于JMS協議，Java編寫的Apache頂級開源項目，支持點對點和發布訂閱兩種模式。
a、點對點（point-to-point）：消息發送到指定的隊列，每條消息只有一個消費者能夠消費，基于拉模型
b、發布訂閱（publish/subscribe）：消息發送到主題Topic上，每條消息會被訂閱該Topic的所有消費者各自消費，基于推模型
2）延遲隊列實現：需要延遲的消息會先存儲在JobStore中，通過異步線程任務JobScheler