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