常用消息队列介绍
消息隊列是分布式應用間交換信息的重要組件，消息隊列可駐留在內存或磁盤上, 隊列可以存儲消息直到它們被應用程序讀走。
通過消息隊列，應用程序可以在不知道彼此位置的情況下獨立處理消息，或者在處理消息前不需要等待接收此消息。
所以消息隊列可以解決應用解耦、異步消息、流量削鋒等問題，是實現高性能、高可用、可伸縮和最終一致性架構中不可以或缺的一環。
現在比較常見的消息隊列產品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。
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，進行測試
2 RabbitMQ
RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標準實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
幾個重要概念：
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，進行消息路由，將消息投遞到一個或多個隊列里。
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切換開銷。
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）。
一般應用在大數據日志處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。
5 RocketMQ
RocketMQ是阿里開源的消息中間件，純Java開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。RocketMQ思路起源于Kafka，但并不是簡單的復制，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景，支撐了阿里多次雙十一活動。
因為是阿里內部從實踐到產品的產物，因此里面很多接口、api并不是很普遍適用。可靠性毋庸置疑，而且與Kafka一脈相承（甚至更優），性能強勁，支持海量堆積。
6 Apollo
Apache ActiveMQ 是一個非常流行、強大、開源的消息和集成模式（Integration Patterns）服務器，速度快、支持多種跨語言客戶端和協議，易于使用企業集成模式（Enterprise Integration Patterns），擁有許多先進的特性，完全支持JMS 1.1和J2EE 1.4規范。ActiveMQ 基于Apache 2.0許可。
Apollo 以 ActiveMQ原型為基礎，是一個更快、更可靠、更易于維護的消息代理工具。Apache 號稱 Apollo 為最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協議）服務器。
Apollo的特性如下：
- 支持Stomp 1.0和Stomp 1.1協議
- 主題和隊列
- 隊列瀏覽器
- 主題持久訂閱
- 鏡像隊列
- 可靠的消息傳遞
- 消息過期和交換
- 消息選擇器
- JAAS驗證
- 基于ACL的授權
- 支持SSL/TLS，證書驗證
- REST Management API
選擇哪個中間件？
到底應該哪個方案，還是要看具體的需求。在我們的設計中，MQ的功能與業務無關，因此優先考慮使用已有的中間件搭建。那么具本選擇哪個中間件呢？先來梳理下我們對MQ的需求：
功能需求
如前文所述，除了最基本生產消費模型，還需要MQ能支持REQUEST-REPLY模型，以提供對同步調用的支持。 此外，如果MQ能提供PUBLISH-SUBSCRIBE模型，則事件代理的實現可以更加簡單。
性能需求
考慮未來一到兩年內產品的發展，消息隊列的呑吐量預計不會超過 1W qps，但由單條消息延遲要求較高，希望盡量的短。
可用性需求
因為是在線服務，因此需要較高的可用性，但充許有少量消息丟失。
易用性需求
包括學習成本、初期的開發部署成本、日常的運維成本等。
橫向對比
ActiveMQ與RabbitMQ在很多方面都很相似，但ActiveMQ對非JAVA生態的支持不及rabbitMQ, 加之精力有限，因此本文重點關注RabbitMQ。
特性
ActiveMQ
RabbitMQ
Kafka
RocketMQ
PRODUCER-COMSUMER
支持
支持
支持
支持
PUBLISH-SUBSCRIBE
支持
支持
支持
支持
REQUEST-REPLY
支持
支持
-
支持
API完備性
高
高
高
低（靜態配置）
多語言支持
支持，JAVA優先
語言無關
支持，JAVA優先
支持
單機呑吐量
萬級
萬級
十萬級
單機萬級
消息延遲
-
微秒級
毫秒級
-
可用性
高（主從）
高（主從）
非常高（分布式）
高
消息丟失
-
低
理論上不會丟失
-
消息重復
-
可控制
理論上會有重復
-
文檔的完備性
高
高
高
中
提供快速入門
有
有
有
無
首次部署難度
-
低
中
高
注： - 表示尚未查找到準確數據
總結
消息隊列的選型需要根據具體應用需求而定，ZeroMQ小而美，RabbitMQ大而穩，Kakfa和RocketMQ快而強勁。
RocketMQ雖然目前還很多不完善，但是一旦在Apache孵化成為頂級項目，前途也是不可限量的。
參考資料
https://blog.csdn.net/cws1214/article/details/52922267
https://blog.csdn.net/liuxinghao/article/details/60875715
https://blog.csdn.net/pkueecser/article/details/50613989
轉載于:https://www.cnblogs.com/willem-xin/p/10258225.html
總結
- 上一篇： jar指的是什么文件格式
- 下一篇： 100行代码实现了多线程,批量写入,文件