文章目錄

• 1 你們為什么選擇了RabbitMQ而不是其它的MQ？
• 2 RabbitMQ如何確保消息的不丟失？
• 3 RabbitMQ如何避免消息堆積？
• 4 RabbitMQ如何保證消息的有序性？
• 5 如何防止MQ消息被重復消費？
• 6 如何保證RabbitMQ的高可用？
• 7 使用MQ可以解決那些問題？

目前累計服務客戶成百上千，積累了豐富的產品開發及服務經驗。以網站設計水平和技術實力，樹立企業形象，為客戶提供成都做網站、成都網站建設、網站策劃、網頁設計、網絡營銷、VI設計、網站改版、漏洞修補等服務。創新互聯始終以務實、誠信為根本，不斷創新和提高建站品質，通過對領先技術的掌握、對創意設計的研究、對客戶形象的視覺傳遞、對應用系統的結合，為客戶提供更好的一站式互聯網解決方案，攜手廣大客戶，共同發展進步。1 你們為什么選擇了RabbitMQ而不是其它的MQ？

如圖：

話術：

kafka是以吞吐量高而聞名，不過其數據穩定性一般，而且無法保證消息有序性。我們公司的日志收集也有使用，業務模塊中則使用的RabbitMQ。

阿里巴巴的RocketMQ基于Kafka的原理，彌補了Kafka的缺點，繼承了其高吞吐的優勢，其客戶端目前以Java為主。但是我們擔心阿里巴巴開源產品的穩定性，所以就沒有使用。

RabbitMQ基于面向并發的語言Erlang開發，吞吐量不如Kafka，但是對我們公司來講夠用了。而且消息可靠性較好，并且消息延遲極低，集群搭建比較方便。支持多種協議，并且有各種語言的客戶端，比較靈活。Spring對RabbitMQ的支持也比較好，使用起來比較方便，比較符合我們公司的需求。

綜合考慮我們公司的并發需求以及穩定性需求，我們選擇了RabbitMQ。

2 RabbitMQ如何確保消息的不丟失？

話術：

RabbitMQ針對消息傳遞過程中可能發生問題的各個地方，給出了針對性的解決方案：

• 生產者發送消息時可能因為網絡問題導致消息沒有到達交換機：
  • RabbitMQ提供了publisher confirm機制
    • 生產者發送消息后，可以編寫ConfirmCallback函數
    • 消息成功到達交換機后，RabbitMQ會調用ConfirmCallback通知消息的發送者，返回ACK
    • 消息如果未到達交換機，RabbitMQ也會調用ConfirmCallback通知消息的發送者，返回NACK
    • 消息超時未發送成功也會拋出異常
• 消息到達交換機后，如果未能到達隊列，也會導致消息丟失：
  • RabbitMQ提供了publisher return機制
    • 生產者可以定義ReturnCallback函數
    • 消息到達交換機，未到達隊列，RabbitMQ會調用ReturnCallback通知發送者，告知失敗原因
• 消息到達隊列后，MQ宕機也可能導致丟失消息：
  • RabbitMQ提供了持久化功能，集群的主從備份功能
    • 消息持久化，RabbitMQ會將交換機、隊列、消息持久化到磁盤，宕機重啟可以恢復消息
    • 鏡像集群，仲裁隊列，都可以提供主從備份功能，主節點宕機，從節點會自動切換為主，數據依然在
• 消息投遞給消費者后，如果消費者處理不當，也可能導致消息丟失
  • SpringAMQP基于RabbitMQ提供了消費者確認機制、消費者重試機制，消費者失敗處理策略：
    • 消費者的確認機制：
      • 消費者處理消息成功，未出現異常時，Spring返回ACK給RabbitMQ，消息才被移除
      • 消費者處理消息失敗，拋出異常，宕機，Spring返回NACK或者不返回結果，消息不被異常
    • 消費者重試機制：
      • 默認情況下，消費者處理失敗時，消息會再次回到MQ隊列，然后投遞給其它消費者。Spring提供的消費者重試機制，則是在處理失敗后不返回NACK，而是直接在消費者本地重試。多次重試都失敗后，則按照消費者失敗處理策略來處理消息。避免了消息頻繁入隊帶來的額外壓力。
    • 消費者失敗策略：
      • 當消費者多次本地重試失敗時，消息默認會丟棄。
      • Spring提供了Republish策略，在多次重試都失敗，耗盡重試次數后，將消息重新投遞給指定的異常交換機，并且會攜帶上異常棧信息，幫助定位問題。

3 RabbitMQ如何避免消息堆積？

話術：

消息堆積問題產生的原因往往是因為消息發送的速度超過了消費者消息處理的速度。因此解決方案無外乎以下三點：

• 提高消費者處理速度
• 增加更多消費者
• 增加隊列消息存儲上限

1）提高消費者處理速度

消費者處理速度是由業務代碼決定的，所以我們能做的事情包括：

• 盡可能優化業務代碼，提高業務性能
• 接收到消息后，開啟線程池，并發處理多個消息

優點：成本低，改改代碼即可

缺點：開啟線程池會帶來額外的性能開銷，對于高頻、低時延的任務不合適。推薦任務執行周期較長的業務。

2）增加更多消費者

一個隊列綁定多個消費者，共同爭搶任務，自然可以提供消息處理的速度。

優點：能用錢解決的問題都不是問題。實現簡單粗暴

缺點：問題是沒有錢。成本太高

3）增加隊列消息存儲上限

在RabbitMQ的1.8版本后，加入了新的隊列模式：Lazy Queue

這種隊列不會將消息保存在內存中，而是在收到消息后直接寫入磁盤中，理論上沒有存儲上限。可以解決消息堆積問題。

優點：磁盤存儲更安全；存儲無上限；避免內存存儲帶來的Page Out問題，性能更穩定；

缺點：磁盤存儲受到IO性能的限制，消息時效性不如內存模式，但影響不大。

4 RabbitMQ如何保證消息的有序性？

話術：

其實RabbitMQ是隊列存儲，天然具備先進先出的特點，只要消息的發送是有序的，那么理論上接收也是有序的。不過當一個隊列綁定了多個消費者時，可能出現消息輪詢投遞給消費者的情況，而消費者的處理順序就無法保證了。

因此，要保證消息的有序性，需要做的下面幾點：

• 保證消息發送的有序性
• 保證一組有序的消息都發送到同一個隊列
• 保證一個隊列只包含一個消費者

5 如何防止MQ消息被重復消費？

話術：

消息重復消費的原因多種多樣，不可避免。所以只能從消費者端入手，只要能保證消息處理的冪等性就可以確保消息不被重復消費。

而冪等性的保證又有很多方案：

• 給每一條消息都添加一個唯一id，在本地記錄消息表及消息狀態，處理消息時基于數據庫表的id唯一性做判斷
• 同樣是記錄消息表，利用消息狀態字段實現基于樂觀鎖的判斷，保證冪等
• 基于業務本身的冪等性。比如根據id的刪除、查詢業務天生冪等；新增、修改等業務可以考慮基于數據庫id唯一性、或者樂觀鎖機制確保冪等。本質與消息表方案類似。

6 如何保證RabbitMQ的高可用？

話術：

要實現RabbitMQ的高可用無外乎下面兩點：

• 做好交換機、隊列、消息的持久化
• 搭建RabbitMQ的鏡像集群，做好主從備份。當然也可以使用仲裁隊列代替鏡像集群。

7 使用MQ可以解決那些問題？

話術：

RabbitMQ能解決的問題很多，例如：

• 解耦合：將幾個業務關聯的微服務調用修改為基于MQ的異步通知，可以解除微服務之間的業務耦合。同時還提高了業務性能。
• 流量削峰：將突發的業務請求放入MQ中，作為緩沖區。后端的業務根據自己的處理能力從MQ中獲取消息，逐個處理任務。流量曲線變的平滑很多
• 延遲隊列：基于RabbitMQ的死信隊列或者DelayExchange插件，可以實現消息發送后，延遲接收的效果。

你是否還在尋找穩定的海外服務器提供商？創新互聯www.cdcxhl.cn海外機房具備T級流量清洗系統配攻擊溯源，準確流量調度確保服務器高可用性，企業級服務器適合批量采購，新人活動首月15元起，快前往官網查看詳情吧

本文名稱：RabbitMQ面試篇-創新互聯
標題路徑：http://vcdvsql.cn/article38/iiepp.html

成都網站建設公司_創新互聯，為您提供網站內鏈、App設計、手機網站建設、域名注冊、網站設計、標簽優化

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯