關于消息隊列的優(yōu)缺點，看這篇就行

在項目中為什么要使用消息隊列

消息隊列使用場景主要有三個：

解耦，異步，削峰

1、解耦

如上圖所示，可能存在某一個系統(tǒng)產(chǎn)生關鍵數(shù)據(jù)，所有系統(tǒng)都需要其進行提供數(shù)據(jù)，導致A系統(tǒng)與要提供數(shù)據(jù)系統(tǒng)產(chǎn)生耦合，系統(tǒng)拓展，其他系統(tǒng)的需求修改都會導致A系統(tǒng)產(chǎn)生修改。

2、異步

如果用戶一個點擊，需要幾個系統(tǒng)間的一系列反應，同時每一個系統(tǒng)肯都存在一定的耗時，那么可以使用mq對不同的系統(tǒng)進行發(fā)送命令，進行異步操作。

3、削峰

主要是如果存在用戶使用的高峰期，例如存在大量的請求訪問數(shù)據(jù)庫（mysql每秒2000個請求），超過就會卡死，我們使用MQ作為類似于緩沖區(qū)的作用，高峰取時在MQ中進行大量請求積壓，處理器按照自己的最大處理能力取請求量，等請求期過后再把它消耗掉。

消息隊列有什么缺點

1、系統(tǒng)的可用性降低：很多服務都依賴于MQ，一旦MQ故障，系統(tǒng)崩潰。

2、系統(tǒng)變的復雜，序列考慮問題變多：發(fā)送消息重復，多了，亂序，丟掉。

3.、一致性問題：系統(tǒng)A給BCD發(fā)送，只有都成功才返回成功，結果BC成功，但是D失敗，但是返回頁面結果是成功。

每一個MQ都有什么異同和適用場景

ActiveMQ

最早大家都用ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，單機吞吐量，萬級，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級，響應為ms級別，有較低的概率丟失數(shù)據(jù)。

RabbitMQ

單機吞吐率萬級，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級，但是適合于中小型企業(yè)，因為自帶了友好的監(jiān)控和維護界面，社區(qū)相對比較活躍，幾乎每個月都發(fā)布幾個版本分，在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些，但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因為他做的實現(xiàn)機制比較重，同時語言在國內(nèi)很少有人會。

RocketMQ

單機吞吐量10萬級，RocketMQ也是可以支撐高吞吐的一種MQ，topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降，這是RocketMQ的一大優(yōu)勢，在同等機器下，可以支撐大量的topic，可用性非常高，分布式架構，在阿里大規(guī)模應用過，有阿里品牌保障，日處理消息上百億之多，可以做到大規(guī)模吞吐，性能也非常好，分布式擴展也很方便，源碼是JAVA。

Kafka

單機吞吐量10萬級別，這是kafka最大的優(yōu)點，就是吞吐量高。一般配合大數(shù)據(jù)類的系統(tǒng)來進行實時數(shù)據(jù)計算、日志采集等場景。topic從幾十個到幾百個的時候，吞吐量會大幅度下降。

所以在同等機器下，kafka盡量保證topic數(shù)量不要過多。如果要支撐大規(guī)模topic，需要增加更多的機器資源,可用性非常高，kafka是分布式的，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)，不會導致不可用。