消息隊列常見面試題

1.爲何要用消息隊列

解耦、異步、削峯

• A系統調用B系統、C系統，傳統的調用是直接調用，可是當B系統說我不須要你提供數據了，這時候A須要改代碼，Ｃ系統說我不須要某個字段了，這時候Ａ也要改代碼，若是又多了一個D系統，A又要寫代碼。爲了實現解耦，引入消息隊列，Ａ將產生的數據丟到消息隊列中，哪一個系統須要 哪一個系統就去取；
• A系統調用B系統，B系統因爲某個須要調用第三方接口超時，致使A系統響應速度慢，而B系統的好壞又不會影響業務邏輯，因此能夠改成A異步調用B，A將消息丟到消息隊列中，B系統訂閱消息，實現A的快速響應；
• 當大量流量請求到系統A時，因爲數據庫的處理能力有限，形成數據庫鏈接異常。使用消息隊列，大量請求先丟到消息隊列中，系統A使用按批拉數據的方式，批量處理數據，生產中，高峯期短暫的消息積壓是容許的。

2.使用消息隊列有什麼缺點

• 系統複雜性增長：加了消息隊列，須要保證消息不會重複消費，須要保證消息的可靠性，須要保證消息隊列的高可用
• 系統的可用性下降：若是消息隊列掛了，那麼系統也會受到影響

3.爲何選用RocketMQ；RocketMQ和ActiveMQ的區別

RocketMQ模型簡單、接口易用，在阿里大規模使用，社區活躍，單機吞吐量10萬級，可用性很是高，消息理論上不會丟失；

• ActiveMQ嚴格遵循JMS規範，可持久化到內存、文件、數據庫，可用性高主要是主從，多語言支持，消失丟失率低；
• RocketMQ持久化到磁盤文件，可用性很是高，支持分佈式，只支持Java，消息理論上不會丟失；

4.RocketMQ是怎麼保證系統高可用的？

• 多Master部署，防止單點故障；
• 主從結構，消息冗餘，防止消息丟失；

5.MQ可否保證消息必達，即消息的可靠性？

爲了下降消息丟失的機率，MQ須要進行超時和重傳

(1) MQ-client-sender 發送消息給MQ-server

(2) MQ-server接收到消息後，發送 ACK消息給發送方

(3) MQ-client-sender 接收到 ACK消息後，則 消息已經投遞成功

若是上述 2 消息丟失或者超時，MQ-client-sender 內的 timer 會重發消息，直到收到 ACK消息，若是重試N次後還未收到，則回調發送失敗。須要注意的是，這個過程當中 MQ-server 可能會收到同一條消息的屢次重發。

對每條消息，MQ系統內部必須生成一個inner-msg-id，做爲去重和冪等的依據，這個內部消息ID的特性是：

• 全局惟一
• MQ生成，具有業務無關性，對消息發送方和消息接收方屏蔽

(4) MQ-server 將消息發送給 MQ-client-receiver

(5) MQ-client-receiver 獲得消息處理業務邏輯

(6) MQ-client-receiver 回覆 ACK消息給 MQ-server

(7) MQ-server收到 ACK消息，將已消費的消息刪除

若是上述 6 消息丟失或者超時，MQ-server 內的 timer 會重發消息，直到 MQ-server 收到ACK消息 而且 將已消費的消息刪除，這個過程也可能會重發屢次，MQ-client-receiver 也可能會收到同一條消息的屢次重發。

須要強調的是，MQ-client-receiver 回ACK給 MQ-server，是消息消費業務方的主動調用行爲，不能由 MQ-client-sender 自動發起，由於MQ系統不知道消費方何時真正消費成功。

爲了保證業務冪等性，業務消息體中，必須有一個biz-id，做爲去重和冪等的依據，這個業務ID的特性是：

• 對於同一個業務場景，全局惟一
• 由業務消息發送方生成，業務相關，對MQ透明
• 由業務消息消費方負責判重，以保證冪等

最多見的業務ID有：支付ID，訂單ID，帖子ID等。

歡迎關注個人公衆號~ 搜索公衆號： 碼咖 或者 掃描下方二維碼：