如何選擇合適的開源消息中間件，開源消息中間件
原創文章轉載請注明出處：@協思, 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，希望本文對你的選擇性障礙有所緩解。
