消息隊列一---(為什么使用消息隊列和優(yōu)缺點區(qū)別)
應用場景
為什么使用消息隊列(面試官看你思不思考)
其實就是問問你消息隊列都有哪些使用場景，然后你項目里具體是什么場景，說說你在這個場景里用消息隊列是什么？
面試官問你這個問題，期望的一個回答是說，你們公司有個什么業(yè)務場景，這個業(yè)務場景有個什么技術挑戰(zhàn)，如果不用 MQ 可能會很麻煩，但是你現(xiàn)在用了 MQ 之后帶給了你很多的好處。
先說一下消息隊列常見的使用場景吧，其實場景有很多，但是比較核心的有 3 個：解耦、異步、削峰。
解耦
一個系統(tǒng)(模塊)調(diào)用多個系統(tǒng)(模塊)的場景
多個系統(tǒng)的添加或減少都需修改調(diào)用系統(tǒng)的代碼
且不需要同步調(diào)用接口的情況
異步
涉及到時間消耗問題,當一個信息傳入同時保存到多個系統(tǒng),
期間需要一個時間消耗,
這時只需要信息先保存當前系統(tǒng),剩下的放入消息隊列
削峰
每個系統(tǒng)性能都是有極限的
類似淘寶雙十一,數(shù)據(jù)量猛增,
這個時候就需要把用戶的請求放入消息隊列中,
每次從隊列中取出最大數(shù)據(jù)(剛好不會使系統(tǒng)崩潰的數(shù)據(jù)),
這樣請求就會堆積在消息隊列中,
等到閑時請求就少了,但系統(tǒng)人以最大吞吐去處理數(shù)據(jù),
所以堆積消息很快會被解決
消息隊列的優(yōu)缺點
優(yōu)點
在特殊場景下有其對應的好處，解耦、異步、削峰。
缺點
-
系統(tǒng)可用性降低
系統(tǒng)引入的外部依賴越多,越容易掛掉.
MQ掛掉,全部涼涼
-
系統(tǒng)復雜度提高
如何保證消息沒有被重復消費
怎么處理消息丟失的情況
怎么保證消息的順序型
-
一致性問題
A 系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統(tǒng)那里，BD 兩個系統(tǒng)寫庫成功了，結(jié)果 C 系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致了。
Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么優(yōu)缺點？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數(shù)量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數(shù)據(jù)類的系統(tǒng)來進行實時數(shù)據(jù)計算、日志采集等場景 |
| topic 數(shù)量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優(yōu)勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數(shù)量不要過多，如果要支撐大規(guī)模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內(nèi) |
| 可用性 | 高，基于主從架構實現(xiàn)高可用 | 同 ActiveMQ | 非常高，分布式架構 | 非常高，分布式，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數(shù)據(jù) | 基本不丟 | 經(jīng)過參數(shù)優(yōu)化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基于 erlang 開發(fā)，并發(fā)能力很強，性能極好，延時很低 | MQ 功能較為完善，還是分布式的，擴展性好 | 功能較為簡單，主要支持簡單的 MQ 功能，在大數(shù)據(jù)領域的實時計算以及日志采集被大規(guī)模使用 |
- 一般的業(yè)務系統(tǒng)要引入 MQ，最早大家都用 ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
- 后來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也高；
- 不過現(xiàn)在確實越來越多的公司會去用 RocketMQ，確實很不錯，畢竟是阿里出品，但社區(qū)可能有突然黃掉的風險（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區(qū)，絕對不會黃。
- 所以中小型公司，技術實力較為一般，技術挑戰(zhàn)不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發(fā)實力較強，用 RocketMQ 是很好的選擇。
- 如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用 Kafka 是業(yè)內(nèi)標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。
浙公網(wǎng)安備 33010602011771號