來源：https://dwz.cn/y8GDcqOh
在項(xiàng)目中為什么要使用消息隊(duì)列
消息隊(duì)列使用場景主要有三個(gè)：
解耦，異步，削峰
1、解耦
如上圖所示，可能存在某一個(gè)系統(tǒng)產(chǎn)生關(guān)鍵數(shù)據(jù)，所有系統(tǒng)都需要其進(jìn)行提供數(shù)據(jù)，導(dǎo)致A系統(tǒng)與要提供數(shù)據(jù)系統(tǒng)產(chǎn)生耦合，系統(tǒng)拓展，其他系統(tǒng)的需求修改都會(huì)導(dǎo)致A系統(tǒng)產(chǎn)生修改。
2、異步
如果用戶一個(gè)點(diǎn)擊，需要幾個(gè)系統(tǒng)間的一系列反應(yīng)，同時(shí)每一個(gè)系統(tǒng)肯都存在一定的耗時(shí)，那么可以使用mq對不同的系統(tǒng)進(jìn)行發(fā)送命令，進(jìn)行異步操作。
3、削峰
主要是如果存在用戶使用的高峰期，例如存在大量的請求訪問數(shù)據(jù)庫（MySQL每秒2000個(gè)請求），超過就會(huì)卡死，我們使用MQ作為類似于緩沖區(qū)的作用，高峰取時(shí)在MQ中進(jìn)行大量請求積壓，處理器按照自己的最大處理能力取請求量，等請求期過后再把它消耗掉。
消息隊(duì)列有什么缺點(diǎn)
1、系統(tǒng)的可用性降低：很多服務(wù)都依賴于MQ，一旦MQ故障，系統(tǒng)崩潰。
2、系統(tǒng)變的復(fù)雜，序列考慮問題變多：發(fā)送消息重復(fù)，多了，亂序，丟掉。
3.、一致性問題：系統(tǒng)A給BCD發(fā)送，只有都成功才返回成功，結(jié)果BC成功，但是D失敗，但是返回頁面結(jié)果是成功。
每一個(gè)MQ都有什么異同和適用場景
ActiveMQ
最早大家都用ActiveMQ，但是現(xiàn)在確實(shí)大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗(yàn)證，社區(qū)也不是很活躍，單機(jī)吞吐量，萬級，吞吐量比RocketMQ和Kafka要低了一個(gè)數(shù)量級，響應(yīng)為ms級別，有較低的概率丟失數(shù)據(jù)。
RabbitMQ
單機(jī)吞吐率萬級，吞吐量比RocketMQ和Kafka要低了一個(gè)數(shù)量級，但是適合于中小型企業(yè)，因?yàn)樽詭Я擞押玫谋O(jiān)控和維護(hù)界面，社區(qū)相對比較活躍，幾乎每個(gè)月都發(fā)布幾個(gè)版本分，在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些，但是問題也是顯而易見的，RabbitMQ確實(shí)吞吐量會(huì)低一些，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重，同時(shí)語言在國內(nèi)很少有人會(huì)。
RocketMQ
單機(jī)吞吐量10萬級，RocketMQ也是可以支撐高吞吐的一種MQ，topic可以達(dá)到幾百，幾千個(gè)的級別，吞吐量會(huì)有較小幅度的下降，這是RocketMQ的一大優(yōu)勢，在同等機(jī)器下，可以支撐大量的topic，可用性非常高，分布式架構(gòu)，在阿里大規(guī)模應(yīng)用過，有阿里品牌保障，日處理消息上百億之多，可以做到大規(guī)模吞吐，性能也非常好，分布式擴(kuò)展也很方便，源碼是JAVA。
Kafka
單機(jī)吞吐量10萬級別，這是kafka最大的優(yōu)點(diǎn)，就是吞吐量高。一般配合大數(shù)據(jù)類的系統(tǒng)來進(jìn)行實(shí)時(shí)數(shù)據(jù)計(jì)算、日志采集等場景。topic從幾十個(gè)到幾百個(gè)的時(shí)候，吞吐量會(huì)大幅度下降。
所以在同等機(jī)器下，kafka盡量保證topic數(shù)量不要過多。如果要支撐大規(guī)模topic，需要增加更多的機(jī)器資源,可用性非常高，kafka是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用。
