目錄
衡量一個MQ的指標，主要有三個方面：服務性能、數據存儲、集羣架構
前言
消息隊列已經逐漸成爲企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成爲異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發RocketMQ等。今天主要來介紹了下幾大主流消息中間件的區別與聯繫。
1. 主流消息中間件介紹——ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規範的JMS Provider實現。它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，並有許多高級功能。
1.1 特點
- ActiveMQ是Apache出品，最流行的，能力強勁的開源消息總線，並且它是一個完全支持JMS規範的消息中間件
- 其豐富的API、多種集羣構建模式使得他成爲業界老牌消息中間件，在中小型企業中應用廣泛!
- MQ衡量指標：服務性能、數據存儲、集羣架構。
ActiveMQ現在用的比較少，因爲ActiveMQ相比其他的MQ的性能來說比較一般。現如今高併發、大數據的應用場景隨處可見。如果這時候在MQ的選擇上，那麼ActiveMQ就顯得力不從心了。
衡量一個MQ的指標，主要有三個方面：服務性能、數據存儲、集羣架構
- 服務性能：ActiveMQ的性能不是特別好，面對超大規模併發時候，總是會出現各種各樣的小問題，比如阻塞，消息堆積過多，產生一些延遲等等一些問題。
- 數據存儲：ActiveMQ默認採用KahaDB內存存儲方式。也可以採用一些高性能的存儲方式，比如：google的LevelDb 基於內c存的。如果是爲了保證消息的可靠，也可以採用mysql或者oracle數據庫。
- 集羣架構：ActiveMQ流行那麼多年，與其他組件集成的Api也是十分完善的。如果不是特別大的併發場景下，ActiveMQ也是一個不錯的選擇。因爲ActiveMQ的集羣架構模式也是十分好。
1.2 ActiveMQ架構模式
Masrer-Slave模式
主備模式，利用Zookeeper進行兩個或多個節點的協調。其中的主節點是對外提供服務的，而另外的從節點啓動着，但是不對外提供服務。當主節點掛掉，利用Zookeeper進行一個高可用的切換，將Salve節點切換成主節點，繼續對外提供服務。
NetWork模式
本質是兩組主備模式的集成，中間用NewWork網關，做一個連接配置，就可以實現分佈式集羣。
1.3 ActiveMQ小結
ActiveMQ優點：
- 跨平臺(JAVA編寫與平臺無關，ActiveMQ幾乎可以運行在任何的JVM上)
- 可以用JDBC：可以將數據持久化到數據庫。雖然使用JDBC會降低ActiveMQ的性能，但是數據庫一直都是開發人員最熟悉的存儲介質
- 支持JMS規範：支持JMS規範提供的統一接口
- 支持自動重連和錯誤重試機制
- 有安全機制：支持基於shiro，jaas等多種安全配置機制，可以對Queue/Topic進行認證和授權
- 監控完善：擁有完善的監控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API
- 界面友善：提供的WebConsole可以滿足大部分情況，還有很多第三方的組件可以使用，比如hawtio
ActiveMQ缺點：
- 社區活躍度不及RabbitMQ高
- 根據其他用戶反饋，會出莫名其妙的問題，會丟失消息
- 目前重心放到activemq6.0產品Apollo，對5.x的維護較少
- 不適合用於上千個隊列的應用場景
2. 主流消息中間件介紹——Kafka
Apache Kafka是一個分佈式消息發佈訂閱系統。
它最初由LinkedIn公司基於獨特的設計實現爲一個分佈式的日誌提交系統(a distributed commit log)，之後成爲Apache項目的一部分。Kafka性能高效、可擴展良好並且可持久化。它的分區特性，可複製和可容錯都是其不錯的特性。
2.1 特點
kafka是LinkedIn開源的分佈式發佈-定於消息系統，目前歸屬於Apache頂級項目。
Kafka主要特點是給予Pull的模式來處理消費消息，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸。
0.8版本開始支持複製，不支持事務，對消息的重複、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。這裏可以看出kafka只關注吞吐量。
因此，在使用kafka的時候，注意業務是否允許消息重複、丟失、錯誤等。如果允許的話，kafka是最合適的。因爲它的性能是最高的。即使在廉價的服務器上，也能支持單機每秒100k條以上的數據量。所以說它的性能是非常好的。kafka僅僅使用內存進行存儲，只要有足夠的內存，就能夠足夠大的吞吐量。因爲kafka並沒有在磁盤上進行讀寫。
- 快速持久化：可以在O(1)的系統開銷下進行消息持久化；
- 高吞吐：在一臺普通的服務器上既可以達到10W/s的吞吐速率；
- 完全的分佈式系統：Broker、Producer和Consumer都原生自動支持分佈式，自動實現負載均衡；
- 支持同步和異步複製兩種高可用機制；
- 支持數據批量發送和拉取；
- 零拷貝技術(zero-copy)：減少IO操作步驟，提高系統吞吐量；
- 數據遷移、擴容對用戶透明；
- 無需停機即可擴展機器；
- 其他特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制
2.2 kafka架構模式
主要依賴Zookeeper進行協調管理，每一個kafka可以進行副本複製，也就是數據同步。
假如說：有一條數據落在第一個節點上，那麼就會進行repilicate 複製，這樣在運行中每個節點就有一份數據，一共就有三分數據。如果說其中一臺宕機，也能從另外兩個節點中獲取數據。
部署方案建議：跨機房部署。即使有一臺機子宕機，在數據上也是沒有問題的。如果在整個地點宕機了。那麼我們的數據也就丟失了。這也是大公司需要考慮的異地災備。當然kafka主要關注性能的，對於數據的可靠性關注並高。
2.3 kafka小結
kafka優點：
- 客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言；
- 高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；
- 提供完全分佈式架構，並有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；
- 支持批量操作；
- 消費者採用Pull方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次；
- 有優秀的第三方KafkaWeb管理界面Kafka-Manager；
- 在日誌領域比較成熟，被多家公司和多個開源項目使用。
kafka缺點：
- Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長；
- 使用短輪詢方式，實時性取決於輪詢間隔時間；
- 消費失敗不支持重試；
- 支持消息順序，但是一臺代理宕機後，就會產生消息亂序；
- 社區更新較慢。
3. 主流消息中間件介紹——RocketMQ
RocketMQ是阿里開源的消息中間件，目前也已經孵化爲Apache頂級項目。用Java語言實現，在設計時參考了Kafka，並做出了自己的一些改進，消息可靠性上比Kafka更好。RocketMQ在阿里內部被廣泛應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。
3.1 RocketMQ特點：
- 保證消息的順序性，消息按順序消費。
- 提供了豐富的拉取和處理模式。
- 高效的訂閱者，也可以進行水平擴展。
- 承載上億級別的消息堆積能力。
3.2 RocketMQ集羣架構模式
- Master-Slave（主從）模式
- 雙Master模式。
- 雙主雙從模式。
- 多主多從模式。
- 一主多從模式。
RocketMQ集羣拓撲
阿里覺得Zookeeper性能太低，自己搭建了NameServer，這個NameServer代碼也十分精簡，一共也就幾百行代碼。有興趣可以去讀源碼。
3.3 RocketMQ小結
RocketMQ優點：
- 單機支持1萬以上持久化隊列；
- RocketMQ的所有消息都是持久化的，先寫入系統PAGECACHE，然後刷盤，可以保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。
- 模型簡單，接口易用（JMS的接口很多場合並不太實用）；
- 性能非常好，可以允許大量堆積消息在Broker中；
- 支持多種消費模式，包括集羣消費、廣播消費等；
- 各個環節分佈式擴展設計，支持主從和高可用；
- 開發度較活躍，版本更新很快。
RocketMQ缺點：
- 支持的 客戶端語言不多，目前是Java及C++，其中C++還不成熟
- 維護RocketMQ需要專業的團隊
- 商業版收費，有許多功能是不對外提供的。
- 沒有在MQ核心裏實現JMS等接口
4. 爲什麼選擇RabbitMQ？
- ActiveMQ，性能不是很好，因此在高併發的場景下，直接被pass掉了。它的Api很完善，在中小型互聯網公司可以去使用。
- kafka，主要強調高性能，如果對業務需要可靠性消息的投遞的時候。那麼就不能夠選擇kafka了。但是如果做一些日誌收集呢，kafka還是很好的。因爲kafka的性能是十分好的。
- RocketMQ，它的特點非常好。它高性能、滿足可靠性、分佈式事物、支持水平擴展、上億級別的消息堆積、主從之間的切換等等。MQ的所有優點它基本都滿足。但是它最大的缺點：商業版收費。因此它有許多功能是不對外提供的。
那麼說完這三種MQ還有沒有其他MQ能夠選擇呢？有的，也是這次學習的MQ——RabbitMQ。
5. 主流消息中間件介紹——RabbitMQ
RabbitMQ於2007年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。
5.1 RabbitMQ特點
- RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基於AMQP協議來實現。
- AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。
- AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
- RabbitMQ的可靠性是非常好的，數據能夠保證百分之百的不丟失。可以使用鏡像隊列，它的穩定性非常好。所以說在我們互聯網的金融行業。對數據的穩定性和可靠性要求都非常高的情況下，我們都會選擇RabbitMQ。當然沒有kafka性能好，但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的優化。
- RabbitMQ可以構建異地雙活架構，包括每一個節點存儲方式可以採用磁盤或者內存的方式。
5.2 RabbitMQ的集羣架構
- 圖中說的就是，我們可以採用三個節點作爲RabbitMQ的一組集羣，當然可以有許多組。節點與節點之間採用mirror queue。基於這種方式，能夠保證數據百分之百的不丟失。
- 前端可以去做負載均衡，比如負載均衡組件：HA-proxy ，進行TCP級別的負載。
- 如果想做一個高可用的話，就需要藉助keepAlived做一個高可用的配置。
- 比如前端加一個虛擬的VIP，通過VIP路由到指定的負載均衡組件，再有它路由到RabbtMQ的某一個節點。
這就是整個RabbitMQ集羣架構。
能夠實現非常完善，高可用並且性能也十分好，穩定性超強。並且有各種集羣恢復手段。
比如:某一個節點掛了，或者某個磁盤損壞了，它也能進行一個消息修復。
6. 入門RabbitMQ核心概念
RabbitMQ 是一個開源的消息代理和隊列服務器，用來通過普通協議在完全不同的應用之間共享數據（RabbitMQ能夠實現跨語言跨平臺的機制，），RabbitMQ是使用Erlang語言來編寫的，並且RabbitMQ是基於AMQP協議的。
僅僅通過上面一句話，相信大家一定有很多疑惑和問題。
- RabbitM成熟度到底怎麼樣？
- 業界使用度怎麼樣？哪些大廠在使用？爲什麼？
- 包括RabbitMQ到底都有哪些特點?
- RabbitMQ爲什麼要用Erlang語言去編寫？
- 什麼是AMQP協議？AMQP協議裏面的具體的規範又是什麼？
我相信大家跟我一樣都會有這樣的疑惑。那麼我們一起來學習一RabbitMQ吧。
互聯網大廠爲什麼選擇RabbitMQ？
業界使用度怎麼樣？哪些大廠在使用？爲什麼？都有哪些優點？
- 據我瞭解：滴滴、美團、去哪兒、頭條…
這些互聯網大廠都會採用RabbitMQ作爲它底層的消息通信的一個基礎組件。根本原因：
- 開源、性能優秀、穩定性保障
- 提供可靠性消息投遞模式（confirm）、返回模式（return）
- 與SpringAMQP完美的整合、擴展性變得更強、API豐富
- 集羣模式豐富、表達式配置、HA（高可用）模式、鏡像隊列模型
- 保證數據不丟失的前提下做到高可靠性、可用性
RabbiMQ的高性能是如何做到的？
原因就在於它使用了Erlang語言，Erlang語言最初在於交換機領域的架構模式，這樣使得RabbitQ在Broker之間進行數據交互的性能是非常優秀的。
- 還有一點也是取決於作者，RabbitMQ開發的作者在開發RabbitMQ之間，先用Erlang語言做了一個簡單的交換機，然後他驚奇的發現：Erlang的優點：Erlang有着和原生Socket一樣好的延遲效果。
- 相信大家接觸過Socket的朋友，對它的有怎樣的性能有一定的瞭解。像我們耳熟能詳的RPC通信框架。比如說：dubbo，它底層就是採用了Netty，Netty無非就是網絡編程中的高性能之王，它無非就是一個Socket。
- 基於這個特點呢，我們就有了一個充分的選擇RabbitMQ的理由。其實我們選擇RabbitMQ的時候，有一個主要的考量目標就是：當消息入到RabbtMQ節點上的時候，RabbitMQ的延遲以及響應。
什麼是AMQP高級消息隊列協議？
AMQP全稱：Advanced Message Queuing Protocol（高級消息隊列協議）
AMQP定義：是具有現代特徵的二進制協議。是一個提供統一消息服務的應用層標準高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。
它就類似於Java中的JMS。是比較上層的規範，基於這個規範可以開發出各種各項的消息中間件。
- Pubilsher application：生產者應用 生產的消息，扔到Server端。
- Server：指的就是RabbitMQ的節點
- Virtual host:虛擬主機，比較上層的一個路由，類似於路由器這麼一個概念。後續介紹
- Exchange:交換機，生產者直接將消息投遞到Exchange中。但是要經歷3個過程 -》server->Virtual host->Exchange
先確定將消息發送到哪臺服務器，那麼就需要先去建立連接，設置一些地址等等。
- 第二層，投遞到哪個Virtual host 需要定義。
- 第三層，投遞到哪個Exchange也需要定義。
再看Consumer application 消費者的應用端，消費端只需要監聽Message Queue，當隊列中有消息的時候，就拿出來消費。因此在Exchange和Message Queue之間有綁定的關係存在，後續詳細介紹。
AMQP核心概念是什麼？
- server: 又稱Broker,接收客戶端的鏈接，實現AMQP實體服務
- Connection: 鏈接，應用程序與Broker的網絡連接
- Channel:網絡信道，幾乎所有的操作（數據的讀、寫）都在Channel中進行，Channel是進行消息讀寫的通道。客戶端可建立多個Channel，每個Channel代表一個會話任務。
- Message：消息，服務器和應用程序之間傳送的數據，由Properties和Body組成。Properties可以對消息進行修飾，比如消息的優先級、延遲等高級特性；Body則就是消息體內容。
- Virtual host:虛擬地址，用於進行邏輯隔離，最上層的消息路由。一個Virtual host 裏面可以有若干個Exchange和Queue，同一個Virtual Host裏面不能有相同名稱的Exchange和Queue。一種邏輯概念，類似Redis的邏輯數據庫。用來劃分具體的服務。
- Exchange：交換機，接收消息，根據路由鍵轉發消息到綁定的隊列
- Binding:Exchange 和Queue之間的虛擬連接，Binding中可以包含routing key
- Routing key:一個路由股則，虛擬機可用它來確定如何路由一個特定消息。
- Queue:也稱爲message Queue,消息隊列，保存消息並將它們轉發給消費者。
以上核心概念先有一個大概的認知，以後會詳細介紹。
RabbitMQ整體架構模型是什麼樣子的？
- 生產者把消息投遞到Exchange,Exchange投遞到Queue.
- 因此我們的生產者只需要關注把消息投遞到指定的Exchange即可,我們的消費者只需要監聽指定Queue即可。就是這麼簡單的機制。
- 通過圖我們也能看到，生產者不需要關注投遞到哪個隊列，消費也不需要關注是從哪個Exchange上來的，這兩塊沒有耦合的情況。主要是應爲Exchange和Queue有一個綁定的關係。
RabbitMQ消息是如何流轉的？
生產者publisher application 生產消息Message投遞到Exchange上，Exchange綁定MessageQueue，可以綁定過多個MessageQueue，爲什麼三個隊列只有其中一個隊列收到了消息呢？主要是由於Exchange是有一個路由功能的。這個路由就是routing key,這個路由有兩個非常關鍵的點，
- 第一個：你的消息是需要發送到哪個Exchange。
- 第二個：你發消息的時候需要帶上routing key，然後通過Exchange 和 MessageQueue 建立一個綁定關係，通過路由key把消息路由到一個指定的隊列上。然後我們的消費端直接監聽隊列就行了，就可以消費了。