如何選擇合適的開源消息中間件

原創文章轉載請註明出處：@協思, http://zeeman.cnblogs.com

 

咱們要引入消息中間件，勢必要考慮成本收益問題，怎樣達到最高的性價比。不少公司的研發團隊尚未專門的資源投入到基礎設施的研發中，使用開源產品，揚長避短無疑是最好的方式。業界消息中間件的種類繁多，各有側重點，看着網上的一些選型推薦，你會以爲無所適從。但我能夠告訴你的是，能用的真的很少:)。

 

對於通常的電子商務而言，不會爲了性能下降可靠性，由於一個消息的丟失，可能意味着有一筆訂單沒法及時處理。追求極致性能的ZeroMQ通常用在遊戲和工控方面，我們作電商的仍是別添亂了。就規模體量而言，大公司會自研消息隊列，像阿里、新浪、亞馬遜，京東，攜程，據我所知，他們是本身開發維護着一套消息隊列，爲何要本身作，說究竟是他們使用消息隊列的場景模式已經相對固化，須要在這種場景下追求最高的性能。中小公司沒有這樣的資源去作，採用通用的開源產品是很合適的，當你有那麼大的體量時，再本身去發明一套定製輪子。

 

咱們能選擇的有三種：

 

1. ActiveMQ/ApolloMQ

優勢：老牌的消息隊列，使用Java語言編寫。對JMS支持最好，採用多線程併發，資源消耗比較大。若是你的主語言是Java，能夠重點考慮。

缺點：因爲歷史悠久，歷史包袱較多，版本更新很緩慢。集羣模式須要依賴Zookeeper實現。最新架構的產品被命名爲Apollo，號稱下一代ActiveMQ，目前案例較少。

 

2. RocketMQ/Kafka

優勢：專爲海量消息傳遞打造，主張使用拉模式，自然的集羣、HA、負載均衡支持。話說仍是那句話，適合不適合看你有沒有那麼大的量。

缺點：所謂魚和熊掌不可兼得，放棄了一些消息中間件的靈活性，使用的場景較窄，需關注你的業務模式是否契合，不然山寨變相使用很彆扭。除此以外，RocketMQ沒有.NET下的客戶端可用。RocketMQ身出名門，但使用者很少，生態較小，畢竟消息量能達到這種體量的公司很少，你也能夠直接去購買阿里雲的消息服務。Kafka生態完善，其代碼是用Scala語言寫成，可靠性比RocketMQ低一些。

 

3. RabbitMQ

優勢：生態豐富，使用者衆，有不少人在前面踩坑。AMQP協議的領導實現，支持多種場景。淘寶的MySQL集羣內部有使用它進行通信，OpenStack開源雲平臺的通訊組件，最早在金融行業獲得運用。

缺點：Erlang代碼你Hold得住不? 雖然Erlang是自然集羣化的，但RabbitMQ在高可用方面作起來還不是特別駕輕就熟，別相信廣告。

 

若是你不着急使用，也能夠觀望一下Redis做者的新產品Disque，還有Go語言寫的Nsq也有不錯的表現。

 

等你每一個產品都做了測試就會發現，都有不爽的地方，畢竟不是爲你量身打造的，因此我前面說能選擇的很少。我建議使用的時候遵照AMTP或者STOMP規範，在規範之下，Client SDK和Service Broker是可替換的，無論你用哪一種語言均可以在Github上找到一堆SDK，這兩種規範ActiveMQ和RabbitMQ都是支持的，Kafka自成一派，基本上大多數人用不上。ActiveMQ和RabbitMQ之間對於有.NET背景的團隊建議使用RabbitMQ，但願本文對你的選擇性障礙有所緩解。