文章目錄

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

目前累計服務客戶成百上千，積累了豐富的產(chǎn)品開發(fā)及服務經(jīng)驗。以網(wǎng)站設計水平和技術實力，樹立企業(yè)形象，為客戶提供成都做網(wǎng)站、成都網(wǎng)站建設、網(wǎng)站策劃、網(wǎng)頁設計、網(wǎng)絡營銷、VI設計、網(wǎng)站改版、漏洞修補等服務。創(chuàng)新互聯(lián)始終以務實、誠信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過對領先技術的掌握、對創(chuàng)意設計的研究、對客戶形象的視覺傳遞、對應用系統(tǒng)的結(jié)合，為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。1 你們?yōu)槭裁催x擇了RabbitMQ而不是其它的MQ？

如圖：

話術：

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

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

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

綜合考慮我們公司的并發(fā)需求以及穩(wěn)定性需求，我們選擇了RabbitMQ。

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

話術：

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

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

3 RabbitMQ如何避免消息堆積？

話術：

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

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

1）提高消費者處理速度

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

• 盡可能優(yōu)化業(yè)務代碼，提高業(yè)務性能
• 接收到消息后，開啟線程池，并發(fā)處理多個消息

優(yōu)點：成本低，改改代碼即可

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

2）增加更多消費者

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

優(yōu)點：能用錢解決的問題都不是問題。實現(xiàn)簡單粗暴

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

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

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

這種隊列不會將消息保存在內(nèi)存中，而是在收到消息后直接寫入磁盤中，理論上沒有存儲上限?？梢越鉀Q消息堆積問題。

優(yōu)點：磁盤存儲更安全；存儲無上限；避免內(nèi)存存儲帶來的Page Out問題，性能更穩(wěn)定；

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

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

話術：

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

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

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

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

話術：

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

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

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

6 如何保證RabbitMQ的高可用？

話術：

要實現(xiàn)RabbitMQ的高可用無外乎下面兩點：

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

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

話術：

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

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

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

本文標題：RabbitMQ面試篇-創(chuàng)新互聯(lián)
當前URL：http://weahome.cn/article/iiepp.html