常見消息中間件比較

要想真正将MQ運用于項目中，要從哪一步開始呢？

我們來想一下，要在項目中使用一個新技術，是不是應該先了解市面上都有哪些常用的架構，是以應該從技術調研開始，選擇合适的架構應用于我們的項目。

那都有哪些中間件可供選擇呢。其實作在主流的消息中間件就4種：kafka、ActiveMQ、RocketMQ、RabbitMQ

下面我們來看一下，他們之間有什麼差別，他們分别應該用于什麼場景

我們先看ActiveMQ。其實一般早些的項目需要引入消息中間件，都是使用的這個MQ，但是現在用的确實不多了，說白了就是有些過時了。我們去它的官網看一看，你會發現官網已經不活躍了，好久才會更新一次。

它的單機吞吐量是萬級，一些小的項目已經夠用了，但對于高并發的網際網路項目完全不夠看。

在高可用上，使用的主從架構的實作。

在消息可靠性上，有較低的機率會丢失資料。

綜合以上，其實這個産品基本可以棄用掉了，我們完全可以使用RabbitMQ來代替它。

rabbitMQ出現後，國内大部分公司都從activeMQ切換到了rabbitMQ，基本代替了activeMQ的位置。它的社群還是很活躍的。

它的單機吞吐量也是萬級，對于需要支援特别高的并發的情況，它是無法擔當重任的。

在高可用上，它使用的是鏡像叢集模式，可以保證高可用。

在消息可靠性上，它是可以保證資料不丢失的，這也是它的一大優點。

同時它也支援一些消息中間件的進階功能，如：消息重試、死信隊列等（後續文章會講到）。

但是，它的開發語言是erlang，國内很少有人精通erlang，是以導緻無法閱讀源碼。

對于大多數中小型公司，不需要面對技術上挑戰的情況，使用它還是比較合适的。而對于一些BAT大型網際網路公司，顯然它就不合适了。

接下來我們來讨論一下我比較喜歡的MQ-RocketMQ，它是阿裡開源的消息中間件，久經沙場，非常靠譜。

它支援高吞吐量，能達到10萬級，能承受網際網路項目高并發的挑戰。

在高可用上，它使用的是分布式架構，可以搭建大規模叢集，性能很高。

在消息可靠性上，通過配置，可以保證資料的絕對不丢失，

同時它支援大量的進階功能，如：延遲消息、事務消息、消息回溯、死信隊列等等（後續文章會單獨講解）。

它非常适合應用于java系統架構中，因為它使用java語言開發的，我們可以去閱讀源碼了解更深的底層原理。

目前來看，它沒有什麼特别的缺點，可以支援高并發下的技術挑戰，可以基于它實作分布式事務，大型網際網路公司和中小型公司都可以選擇使用它來作為消息中間件使用，如果我來做技術選型，我首選的中間件就是它。

kafka的吞吐量被公認為中間件中的翹楚，單機可以支援十幾萬的并發，相當強悍。

在高可用上同樣支援分布式叢集部署。

在消息可靠性上，如果保證異步的性能，可能會出現消息丢失的情況，因為它儲存消息時是先存到磁盤緩沖區的，如果機器出現故障，緩沖區的資料是可能丢失的（後續文章會講到）。

它的功能非常的單一，就是消息的接收與發送，是以不适合應用于許多場景。

它在行業内主要應用于大資料領域，使用它進行使用者行為日志的采集和計算，來實作比如“猜你喜歡”的功能。

是以，如果沒有大資料的需求，一般不會選擇它。