RabbitMQ系列(一)--消息中間件MQ如何去選擇

MQ在項目中的應用很廣泛，本人所在項目組使用的是ActiveMQ，可是後面介紹的RabbitMQ。。。

1、應用場景

一、異步處理

二、流量削峯、秒殺

三、日誌處理，推薦kafka

四、應用解耦

2、衡量指標

咱們從服務性能、數據存儲、集羣結構三個方面去對比，選擇適合本身項目的消息中間件

一、ActiveMQ

特色：

　　早期主流的消息中間件，包括ZeroMQ，可是這幾年使用的不多了，主要在長期維護的項目中使用。API豐富，自己很成熟可是在高併發、大數據

環境下的性能不夠出色，主要試用於中小型項目，有較低的機率丟失數據，最主要是的，官方如今維護的頻率一直在下降，好幾個月才發佈一個版本。

架構：

　　一、Master-Slave模式，經過Zookeeper實現節點切換和故障轉移

　　二、NetWork模式，至關於多套Master-Slave模式，經過NetWork網關進行集成

二、kafka

特色：

　　基於pull模式來處理消息消費，追求高吞吐量，開始的目的是日誌採集和傳輸，0.8版本開始支持複製，不支持事務，對消息的重複、丟失

、錯誤沒有嚴格要求，適合大數據服務的數據計算、日誌採集業務

　　topic數量從幾十到幾百的時候，吞吐量會大幅度降低，自己支持的功能比較簡單，可能有消息重複消費

集羣：

　　經過zookeeper集羣管理多個kafka節點，節點之間相互replication

三、RocketMQ

特色：

　　純Java開發，具有高吞吐量（10W級別）、高可用性、適合大規模分佈式系統應用的特色。思路起源於kafka，對事務的可靠性傳遞和事務性

進行優化，在阿里巴巴普遍應用於交易、充值、流計算、消息推送、日誌流式處理、binglog分發等場景，可是商業版收費

　　MQ功能較爲完善，拓展性好，由於是分佈式的，接口簡易，支持複雜的MQ業務場景，自己是阿里出品，品質有所保障

　　社區維護通常，沒有特別活躍，並且萬一像以前的Dubbo同樣，沒人維護了，就涼了（Dubbo如今已經從新維護，接連發布不少版本）

集羣：

　　master-slave、2M-2S、多主多從等

 

 

四、RabbitMQ

特色：

　　開源的消息代理和隊列服務器，在普通協議在不一樣的應用之間共享數據，使用Erlang編寫（Erlang進行數據交換的性能很好，和原生socket

同樣好的延遲響應效果），遵照AMQP協議，AMQP主要特徵是面向消息、隊列、路由（點對點的發佈/訂閱）、可靠性、安全。適合對數據一致性、

穩定性（100%消息投遞）和可靠性要求很高的場景，對性能和吞吐量的要求其次。

優勢：

　　能達到幾萬級別的吞吐量（和具體的機器配置有關），可是相比kafka和RocketMQ差了很多，由於採用Erlang，時延性是微秒級別，

最重要的是有專門的可視化界面，很方便進行管理，社區很是活躍，功能很完備

缺點：

　　吞吐量的問題，由於是Erlang語言開發，很難去查看源碼。若是存在什麼問題，只能等官方去解決，對其掌控度很低，可是社區活躍

度很高，這個影響也不大的

 

 

綜上：

　　若是是大數據確定推薦kafka，kafka是業內的標準，絕對沒問題。

　　而RocketMQ更加優秀，可是好像商業版收費，社區有黃掉的風險，適合大公司對本身的技術實力有很大自信的，能夠本身維護擴展

　　RabbitMQ方面，Erlang語言是一個限制，畢竟國內精通這個的很少，好在是開源的，穩定支持，適合中小型公司吧

　　本人比較喜歡RocketMQ的，雖然這個系列是學習RabbitMQ，之後確定仍是學習RocketMQ，相對RabbitMQ優勢很明顯。

關於三者詳細對比，能夠參考：經常使用MQ產品的對比，裏面表格對比顯示的很詳細