目錄前端
@(Java消息中間件)java
消息中間件也能夠稱消息隊列,是指用高效可靠的消息傳遞機制進行與平臺無關的數據交流,並基於數據通訊來進行分佈式系統的集成。經過提供消息傳遞和消息隊列模型,能夠在分佈式環境下擴展進程的通訊。當下主流的消息中間件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。其能在不一樣平臺之間進行通訊,經常使用來屏蔽各類平臺協議之間的特性,實現應用程序之間的協同。其優勢在於可以在客戶端和服務器之間進行同步和異步的鏈接,而且在任什麼時候刻均可以將消息進行傳送和轉發。是分佈式系統中很是重要的組件,主要用來解決應用耦合、異步通訊、流量削峯等問題redis
消息中間件幾大主要做用以下:算法
P2P模式包含三個角色:消息隊列(Queue),發送者(Sender),接收者(Receiver)。每一個消息都被髮送到一個特定的隊列,接收者從隊列中獲取消息。隊列保留着消息,直到他們被消費或超時。數據庫
P2P的特色:apache
消息生產者(發佈)將消息發佈到topic中,同時有多個消息消費者(訂閱)消費該消息。和點對點方式不一樣,發佈到topic的消息會被全部訂閱者消費。
queue實現了負載均衡,將producer生產的消息發送到消息隊列中,由多個消費者消費。但一個消息只能被一個消費者接受,當沒有消費者可用時,這個消息會被保存直到有一個可用的消費者。
topic實現了發佈和訂閱,當你發佈一個消息,全部訂閱這個topic的服務都能獲得這個消息,因此從1到N個訂閱者都能獲得一個消息的拷貝瀏覽器
Pub/Sub的特色安全
場景說明:用戶在註冊後,須要發註冊郵件和註冊短信,傳統的作法有兩種:1.串行; 2.並行
1.串行方式:將註冊信息寫入數據庫後,發送註冊郵件,再發送註冊短信,以上三個任務所有完成後才返回給客戶端。 這有一個問題是,郵件,短信並非必須的,它只是一個通知,而這種作法讓客戶端等待沒有必要等待的東西.
2.並行方式:將註冊信息寫入數據庫後,發送郵件的同時,發送短信,以上三個任務完成後,返回給客戶端,並行的方式能提升處理的時間。
假設三個業務節點分別使用50ms,串行方式使用時間150ms,並行使用時間100ms。雖然並性已經提升的處理時間,可是,前面說過,郵件和短信對我正常的使用網站沒有任何影響,客戶端沒有必要等着其發送完成才顯示註冊成功,應該是寫入數據庫後就返回.服務器
3.消息隊列
引入消息隊列後,把發送郵件,短信不是必須的業務邏輯異步處理
由此能夠看出,引入消息隊列後,用戶的響應時間就等於寫入數據庫的時間+寫入消息隊列的時間(能夠忽略不計),引入消息隊列後處理後,響應時間是串行的3倍,是並行的2倍。網絡
這是一個高耦合度系統的例子
先是來一我的找他要求發送數據給一個新的系統H,系統A的同窗要修改代碼而後在那個代碼里加入調用新系統H的流程。
一會那個系統B是個陳舊老系統要下線了,告訴系統A的同窗:別給我發送數據了,接着系統A再次修改代碼再也不給這個系統B。
而後若是要是某個下游系統忽然宕機了呢?
系統A的調用代碼裏是否是會拋異常?那系統A的同窗會收到報警說異常了,結果他還要去care是下游哪一個系統宕機了。
因此在實際的系統架構設計中,若是所有采起這種系統耦合的方式,在某些場景下絕對是不合適的,系統耦合度太嚴重。
而且互相耦合起來並非核心鏈路的調用,而是一些非核心的場景(好比上述的數據消費)致使了系統耦合,這樣會嚴重的影響上下游系統的開發和維護效率。
所以在上述系統架構中,就能夠採用MQ中間件來實現系統解耦。
系統A就把本身的一份核心數據發到MQ裏,下游哪一個系統感興趣本身去消費便可,不須要了就取消數據的消費,以下圖所示:
AMQP協議
AMQP即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標準高級消息隊列協議,是應用層協議的一個開放標準,爲面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息,並不受客戶端/中間件不一樣產品,不一樣開發語言等條件的限制。
優勢:可靠、通用
MQTT協議
MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)是IBM開發的一個即時通信協議,有可能成爲物聯網的重要組成部分。該協議支持全部平臺,幾乎能夠把全部聯網物品和外部鏈接起來,被用來當作傳感器和致動器(好比經過Twitter讓房屋聯網)的通訊協議。
優勢:格式簡潔、佔用帶寬小、移動端通訊、PUSH、嵌入式系統
STOMP協議
STOMP(Streaming Text Orientated Message Protocol)是流文本定向消息協議,是一種爲MOM(Message Oriented Middleware,面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操做的鏈接格式,容許客戶端與任意STOMP消息代理(Broker)進行交互。
優勢:命令模式(非topic\queue模式)
XMPP協議
XMPP(可擴展消息處理現場協議,Extensible Messaging and Presence Protocol)是基於可擴展標記語言(XML)的協議,多用於即時消息(IM)以及在線現場探測。適用於服務器之間的準即時操做。核心是基於XML流傳輸,這個協議可能最終容許因特網用戶向因特網上的其餘任何人發送即時消息,即便其操做系統和瀏覽器不一樣。
優勢:通用公開、兼容性強、可擴展、安全性高,但XML編碼格式佔用帶寬大
其餘基於TCP/IP自定義的協議
有些特殊框架(如:redis、kafka、zeroMq等)根據自身須要未嚴格遵循MQ規範,而是基於TCP\IP自行封裝了一套協議,經過網絡socket接口進行傳輸,實現了MQ的功能。
RocketMQ
阿里系下開源的一款分佈式、隊列模型的消息中間件,原名Metaq,3.0版本名稱改成RocketMQ,是阿里參照kafka設計思想使用java實現的一套mq。同時將阿里系內部多款mq產品(Notify、metaq)進行整合,只維護核心功能,去除了全部其餘運行時依賴,保證核心功能最簡化,在此基礎上配合阿里上述其餘開源產品實現不一樣場景下mq的架構,目前主要多用於訂單交易系統。
具備如下特色:
可以保證嚴格的消息順序
提供針對消息的過濾功能
提供豐富的消息拉取模式
高效的訂閱者水平擴展能力
實時的消息訂閱機制
億級消息堆積能力
官方提供了一些不一樣於kafka的對比差別:
https://rocketmq.apache.org/docs/motivation/
ActiveMQ
Apache下的一個子項目。使用Java徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現,少許代碼就能夠高效地實現高級應用場景。可插拔的傳輸協議支持,好比:in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持經常使用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。
Redis
使用C語言開發的一個Key-Value的NoSQL數據庫,開發維護很活躍,雖然它是一個Key-Value數據庫存儲系統,但它自己支持MQ功能,因此徹底能夠當作一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操做,各執行100萬次,每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不一樣大小的數據。實驗代表:入隊時,當數據比較小時Redis的性能要高於RabbitMQ,而若是數據大小超過了10K,Redis則慢的沒法忍受;出隊時,不管數據大小,Redis都表現出很是好的性能,而RabbitMQ的出隊性能則遠低於Redis。
Kafka
Apache下的一個子項目,使用scala實現的一個高性能分佈式Publish/Subscribe消息隊列系統,具備如下特性:
快速持久化:經過磁盤順序讀寫與零拷貝機制,能夠在O(1)的系統開銷下進行消息持久化;
高吞吐:在一臺普通的服務器上既能夠達到10W/s的吞吐速率;
高堆積:支持topic下消費者較長時間離線,消息堆積量大;
徹底的分佈式系統:Broker、Producer、Consumer都原生自動支持分佈式,依賴zookeeper自動實現複雜均衡;
支持Hadoop數據並行加載:對於像Hadoop的同樣的日誌數據和離線分析系統,但又要求實時處理的限制,這是一個可行的解決方案。
ZeroMQ
號稱最快的消息隊列系統,專門爲高吞吐量/低延遲的場景開發,在金融界的應用中常用,偏重於實時數據通訊場景。ZMQ可以實現RabbitMQ不擅長的高級/複雜的隊列,可是開發人員須要本身組合多種技術框架,開發成本高。所以ZeroMQ具備一個獨特的非中間件的模式,更像一個socket library,你不須要安裝和運行一個消息服務器或中間件,由於你的應用程序自己就是使用ZeroMQ API完成邏輯服務的角色。可是ZeroMQ僅提供非持久性的隊列,若是down機,數據將會丟失。如:Twitter的Storm中使用ZeroMQ做爲數據流的傳輸。
ZeroMQ套接字是與傳輸層無關的:ZeroMQ套接字對全部傳輸層協議定義了統一的API接口。默認支持 進程內(inproc) ,進程間(IPC) ,多播,TCP協議,在不一樣的協議之間切換隻要簡單的改變鏈接字符串的前綴。能夠在任什麼時候候以最小的代價從進程間的本地通訊切換到分佈式下的TCP通訊。ZeroMQ在背後處理鏈接創建,斷開和重連邏輯。
特性:
無鎖的隊列模型:對於跨線程間的交互(用戶端和session)之間的數據交換通道pipe,採用無鎖的隊列算法CAS;在pipe的兩端註冊有異步事件,在讀或者寫消息到pipe的時,會自動觸發讀寫事件。
批量處理的算法:對於批量的消息,進行了適應性的優化,能夠批量的接收和發送消息。
多核下的線程綁定,無須CPU切換:區別於傳統的多線程併發模式,信號量或者臨界區,zeroMQ充分利用多核的優點,每一個核綁定運行一個工做者線程,避免多線程之間的CPU切換開銷。