要想真正將MQ運用於項目中，要從哪一步開始呢？
我們來想一下，要在項目中使用一個新技術，是不是應該先了解市面上都有哪些常用的框架，所以應該從技術調研開始，選擇合適的框架應用於我們的項目。
那都有哪些中間件可供選擇呢。其實現在主流的消息中間件就4種：kafka、ActiveMQ、RocketMQ、RabbitMQ
下面我們來看一下，他們之間有什麼區別，他們分別應該用於什麼場景
ActiveMQ
我們先看ActiveMQ。其實一般早些的項目需要引入消息中間件，都是使用的這個MQ，但是現在用的確實不多了，說白了就是有些過時了。我們去它的官網看一看，你會發現官網已經不活躍了，好久纔會更新一次。
它的單機吞吐量是萬級，一些小的項目已經夠用了，但對於高併發的互聯網項目完全不夠看。
在高可用上，使用的主從架構的實現。
在消息可靠性上，有較低的概率會丟失數據。
綜合以上，其實這個產品基本可以棄用掉了，我們完全可以使用RabbitMQ來代替它。
RabbitMQ
rabbitMQ出現後，國內大部分公司都從activeMQ切換到了rabbitMQ，基本代替了activeMQ的位置。它的社區還是很活躍的。
它的單機吞吐量也是萬級，對於需要支持特別高的併發的情況，它是無法擔當重任的。
在高可用上，它使用的是鏡像集羣模式，可以保證高可用。
在消息可靠性上，它是可以保證數據不丟失的，這也是它的一大優點。
同時它也支持一些消息中間件的高級功能，如：消息重試、死信隊列等（後續文章會講到）。
但是，它的開發語言是erlang，國內很少有人精通erlang，所以導致無法閱讀源碼。
對於大多數中小型公司，不需要面對技術上挑戰的情況，使用它還是比較合適的。而對於一些BAT大型互聯網公司，顯然它就不合適了。
RocketMQ
接下來我們來討論一下我比較喜歡的MQ-RocketMQ，它是阿里開源的消息中間件，久經沙場，非常靠譜。
它支持高吞吐量，能達到10萬級，能承受互聯網項目高併發的挑戰。
在高可用上，它使用的是分佈式架構，可以搭建大規模集羣，性能很高。
在消息可靠性上，通過配置，可以保證數據的絕對不丟失，
同時它支持大量的高級功能，如：延遲消息、事務消息、消息回溯、死信隊列等等（後續文章會單獨講解）。
它非常適合應用於java系統架構中，因爲它使用java語言開發的，我們可以去閱讀源碼瞭解更深的底層原理。
目前來看，它沒有什麼特別的缺點，可以支持高併發下的技術挑戰，可以基於它實現分佈式事務，大型互聯網公司和中小型公司都可以選擇使用它來作爲消息中間件使用，如果我來做技術選型，我首選的中間件就是它。
Kafka
kafka的吞吐量被公認爲中間件中的翹楚，單機可以支持十幾萬的併發，相當強悍。
在高可用上同樣支持分佈式集羣部署。
在消息可靠性上，如果保證異步的性能，可能會出現消息丟失的情況，因爲它保存消息時是先存到磁盤緩衝區的，如果機器出現故障，緩衝區的數據是可能丟失的（後續文章會講到）。
它的功能非常的單一，就是消息的接收與發送，因此不適合應用於許多場景。
它在行業內主要應用於大數據領域，使用它進行用戶行爲日誌的採集和計算，來實現比如“猜你喜歡”的功能。
所以，如果沒有大數據的需求，一般不會選擇它。
好了，本文對消息中間件的技術選型就到這裏，歡迎持續關注文章的後續內容。
往期文章推薦：
