在上篇中，已經對消息隊列的基本概念進行了解釋，本篇中主要詳細的講一下RabbitMq的選擇以及優劣介紹。
----------------------------------------------------------------------------------------------
各項目中使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。今天主要說的是RabbitMq，就來說說他的優勢和劣勢以及特點
RabbitMQ：是一個由Erlang語言開發的AMQP的開源實現。
AMQP：Advanced Meassage Queue，高級消息隊列協議。它是應用層協議的一個開放標準，為面向消息的中間設計，基於此協議的客戶端與消息中間件可傳遞消息，並不受產品、開發語言等條件限制。
RabbitMQ是一個由erlang開發的AMQP（Advanced Message Queue ）的開源實現。AMQP 的出現其實也是應了廣大人民群眾的需求，雖然在同步消息通訊的世界裡有很多公開標準（如 COBAR的 IIOP ，或者是 SOAP 等），但是在異步消息處理中卻不是這樣，只有大企業有一些商業實現（如微軟的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等聯合制定了 AMQP 的公開標準。
RabbitMQ最初起源於金融系統，用於分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗，具體特點：
1、可靠性（Reliablitity）
RabbitMQ 使用一些機制來保證可靠性，如持久化、傳輸確認、發佈確認。
2、靈活的路由（Flexible Routing）
在消息進入隊列之前，通過 Exchange 來路由消息的。對於典型的路由功能，RabbitMQ 已經提供了一些內置的 Exchange 來實現。針對更復雜的路由功能，可以將多個 Exchange 綁定在一起，也通過插件機制實現自己的 Exchange 。
3、消息集群（Clustering）
多個 RabbitMQ 服務器可以組成一個集群，形成一個邏輯 Broker 。
4、高可用（Highly Available Queues）
隊列可以在集群中的機器上進行鏡像，使得在部分節點出問題的情況下隊列仍然可用。
5、多種協議（Multi-protocol）
RabbitMQ 支持多種消息隊列協議，比如 STOMP、MQTT 等等。
6、多語言客戶端（Many Clients）
RabbitMQ 幾乎支持所有常用語言，比如 Java、.NET、Ruby 等等。
7、管理界面（Management UI）
RabbitMQ 提供了一個易用的用戶界面，使得用戶可以監控和管理消息 Broker 的許多方面。
8、跟蹤機制（Tracing）
如果消息異常，RabbitMQ 提供了消息跟蹤機制，使用者可以找出發生了什麼。
9、插件機制（Plugin System）
RabbitMQ 提供了許多插件，來從多方面進行擴展，也可以編寫自己的插件。
說完這些，就要說下，為什麼要選擇RabbitMq，以及RabbitMq在各方面有哪些優勢和劣勢：
RabbitMQ 選型和對比
1.從社區活躍度
按照目前網絡上的資料，RabbitMQ 、activeM 、ZeroMQ 三者中，綜合來看，RabbitMQ 是首選。
2.持久化消息比較
ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我們機器在不可抗力因素等情況下掛掉了，消息不會丟失的機制。
3.綜合技術實現
可靠性、靈活的路由、集群、事務、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系統等等。
RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。當然ZeroMq 也可以做到，不過自己必須手動寫代碼實現，代碼量不小。尤其是可靠性中的：持久性、投遞確認、發佈者證實和高可用性。
4.高併發
毋庸置疑，RabbitMQ 最高，原因是它的實現語言是天生具備高併發高可用的erlang 語言。
5.比較關注的比較， RabbitMQ 和 Kafka
RabbitMq 比Kafka 成熟，在可用性上，穩定性上，可靠性上， RabbitMq 勝於 Kafka （理論上）。
另外，Kafka 的定位主要在日誌等方面， 因為Kafka 設計的初衷就是處理日誌的，可以看做是一個日誌（消息）系統一個重要組件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMq 。
還有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出來很多。
閱讀更多 南京菜菜工作室 的文章
