MQ相关面试题
文章目錄
- 你們項目中哪些地方有使用到 MQ ？
- 為什么需要使用 MQ？
- MQ 如何避免消息堆積的問題？
- MQ 宕機了消息是否會丟失呢？
- 生產者投遞消息，MQ 宕機了如何處理？
- MQ 如何保證消息順序一致性問題?
- 為什么保證了消息順序一致性有可能降低我們消費者消費的速率？解決方案
- MQ 如何保證消息冪等問題?
你們項目中哪些地方有使用到 MQ ？
為什么需要使用 MQ？
1.異步處理（多線程和 MQ）
2.實現解耦
3.流量削峰（MQ 可以實現抗高并發）
可以按場景簡述，錄單流程：用戶手機端填寫錄單流程，服務端接收到請求信息后，存儲數據庫，響應客戶錄單成功，然后寫一條消息到MQ中，具體生成整張保單信息的耗時處理，報單中心模塊監聽MQ信息進行處理，最后，給客戶發送保單成功短信通知。
解耦：客戶端請求到服務端，用戶信息寫入落庫，主線程響應客戶端，另起一個子線程發送MQ系統，耗時操作，讓具體的業務系統慢慢處理。當采用多線程時，主線程和子線程都在同一個服務器上，當服務器當即后，一些操作就無法完成；當使用MQ時，具體業務耗時邏輯的操作有另一個服務器負責去完成，二者沒有關聯，當前這宕機后后者無影響。
流量削峰：
背景：客戶端50個請求到服務端tomcat，而tomcat內部線程容量是有限制的，比如說同時處理只能處理50個任務，當其他任務進行來時，會緩存對隊列中，當處理的請求越來越多就會阻塞線程或者內存溢出。
處理方案：客戶端50個請求到服務端tomcat，而tomcat不做具體耗時邏輯處理，信息落庫后，直接響應客戶端，然后發一條消息到業務系統的MQ中就可以了。
MQ 與多線程實現異步的區別？
1.多線程方式實現異步可能會消耗到我們的 CPU資源，可能會影響到我們業務線程執行 會發生 CPU競爭的問題，例如：單核多線程，cpu上下文切換，會出現卡頓現象
2.MQ 方式實現異步是完全解耦，適合于大型互聯網項目；
3.小的項目可以使用多線程實現異步，大項目建議使用 MQ 實現異步；
MQ 如何避免消息堆積的問題？
1.提高消費者消費的速率；（對我們的消費者實現集群）
2.消費者應該批量形式獲取消息 減少網絡傳輸的次數；
說明：同一個組中多個消費者不會重復消費同一條消息。（均攤策略等等）
理解：
1.產生背景： 生產者投遞消息的速率與我們消費者消費的速率完全不匹配。
2.生產者投遞消息的速率>消費者消費的速率 導致我們消息會堆積在我們 MQ 服務器端中，沒有及時的被消費者消費 所以就會產生消息堆積的問題
3.注意的是：
rabbitMQ 消費者我們的消息消費如果成功的話 消息會被立即刪除。
kafka 或者 rocketMQ 消息消費如果成功的話，消息是不會立即被刪除。
MQ 宕機了消息是否會丟失呢？
不會，因為我們消息會持久化在我們硬盤中。
MQ 如何保證消息不丟失？
1.MQ 服務器端 消息持久化到硬盤
2.生產者 消息確認機制 必須確認消息成功刷盤到硬盤中，才能夠人為消息投遞成功。
3.消費者 必須確認消息消費成功 。
rabbitMQ 中：才會將該消息刪除。
rocketMQ 或者 kafka 中：消息消費后會提交 offse偏移量，消息并不會立即刪除。
（消息刪除通過日志保留策略配置，過了48小時在進行刪除）
生產者投遞消息，MQ 宕機了如何處理？
1.生產者投遞消息會將 msg 消息內容記錄下來，后期如果發生生產者投遞消息失敗；
2.可以根據該日志記錄實現補償機制；
3.補償機制（獲取到該 msg 日志消息內容實現重試）
MQ 如何保證消息順序一致性問題?
將消息需要投遞到同一個 MQ 服務器，同一個分區模型中存放，最終被同一個消費者消費。
核心原理：設定相同的消息 key，根據相同的消息 key 計算 hash 存放在同一個分區中。
產生背景：
MQ服務器集群或者MQ采用分區模型架構存放消息，每個分區對于一個消息者消費消息。
解決消息順序一致性問題：
核心辦法：消息一定要投遞到同一個MQ、同一個分區模型，最終被同一個消費者消費。
根據消息key計算%分區模型總數。
理解：
1.大多數的項目是不需要保證 MQ 消息順序一致性的問題，只有在一些特定的場景可能會需要，比如 MySQL 與 Redis 實現異步同步數據；
2.所有消息需要投遞到同一個 MQ 服務器，同一個分區模型中存放，最終被同一個消費者消費，核心原理：設定相同的消息 key，根據相同的消息 key 計算 hash 存放在同一個分區中。
如果保證了消息順序一致性有可能降低我們消費者消費的速率。
為什么保證了消息順序一致性有可能降低我們消費者消費的速率？解決方案
MQ 如何保證消息冪等問題?
總結
- 上一篇： nacos 持久化 mysql（wind
- 下一篇： kafka java.net.Unkno