136.rabbitmq 的使用場景有哪些？

MQ是一個互聯網架構中常見的解耦利器。

什么時候不使用MQ？

上游實時關注執行結果

?

什么時候使用MQ？

1）數據驅動的任務依賴

2）上游不關心多下游執行結果

3）異步返回執行時間長

136.rabbitmq 有哪些重要的角色？

生產者：消息的創建者，負責創建和推送數據到消息服務器

消費者：消息的接收方，用于處理數據和確認消息

代理：就是RabbitMQ本身，用于扮演快遞的角色，本身并不生產消息

137.rabbitmq 有哪些重要的組件？

ConnectionFactory(連接管理器)：應用程序與RabbitMQ之間建立連接的管理器

Channel(信道)：消息推送使用的通道

Exchange(交換器)：用于接受、分配消息

Queue(隊列)：用于存儲生產者的消息

RoutingKey(路由鍵)：生產者將消息發送給交換器的時候，會指定一個RoutingKey,用來指定這個消息的路由規則，這個RoutingKey需要與交換器類型和綁定鍵(BindingKey)聯合使用才能最終生效。

BindKey(綁定鍵)：用于把交換器的消息綁定到隊列上

138.rabbitmq 中 vhost 的作用是什么？

vhost可以理解為虛擬broker，即mini-RabbitMq server。其內部均還有獨立的queue，exchange，和binding等，但最重要的是，其擁有獨立的權限系統，可以做到vhost范圍的用戶控制。當然從rabbitMq的全局角度，vhost可以作為不同的權限隔離手段（一個典型的例子，就是不同的應用可以跑在不同的vhost種）。

139.rabbitmq 的消息是怎么發送的？

首席先客戶端必須練接到RabbitMQ服務器才能發布和消費消息，客戶端和rabbit server 之間，會創建一個tcp連接，一旦tcp打開并通過了認證，（認證就是你發送給rabbit服務器的用戶名和密碼），你的客戶端和RabbitMq，就創建了一條amqp信道（channel），信道創建在“真實”tcp的虛擬連接，amqp，命令都是通過信道發送出去的，每個信道有唯一的id，不論是發布消息，訂閱隊列都是通過這個信道完成的。

140.rabbitmq 怎么保證消息的穩定性？

提供了事務功能

通過將channel設置為confirm（確認）模式。

141.rabbitmq 怎么避免消息丟失？

?消息持久化 ack確認機制，設置集群鏡像模式，消息補償機制

142.要保證消息持久化成功的條件有哪些？

?申明隊列必須設置持久化durable 設置為true

?消息推送投遞模式必須設置持久化，deliveryMode 設置為2（持久）

消息已經到達持久化的交換機器

消息已經到達持久化隊列

143.rabbitmq 持久化有什么缺點？

將內存中的消息持久化到硬盤上，即使重啟 RabbitMQ，消息也不會丟失。持久化隊列和非持久化隊列的區別是，持久化隊列會被保存在磁盤中，固定并持久的存儲，當 Rabbit 服務重啟后，該隊列會保持原來的狀態在RabbitMQ 中被管理，而非持久化隊列不會被保存在磁盤中，Rabbit 服務重啟后隊列就會消失。非持久化比持久化的優勢就是，由于非持久化不需要保存在磁盤中，所以使用速度就比持久化隊列快。即是非持久化的性能要高于持久化。而持久化的優點就是消息會一直存在，不會隨服務的重啟或服務器的宕機而消失。使用的時候需要根據實際需求來判斷具體如何使用。

144.rabbitmq 有幾種廣播類型？

3.1 第一種模型(直連)

3.2 第二種模型(work quene)

Work queues，也被稱為（Task queues），任務模型。當消息處理比較耗時的時候，可能生產消息的速度會遠遠大于消息的消費速度。長此以往，消息就會堆積越來越多，無法及時處理。此時就可以使用work 模型：讓多個消費者綁定到一個隊列，共同消費隊列中的消息。隊列中的消息一旦消費，就會消失，因此任務是不會被重復執行的。

3.3 第三種模型(fanout)

扇出 也稱為廣播

廣播模式下，消息發送流程是這樣的：

可以有多個消費者

每個消費者有自己的queue（隊列）

每個隊列都要綁定到Exchange（交換機）

生產者發送的消息，只能發送到交換機，交換機來決定要發給哪個隊列，生產者無法決定。

交換機把消息發送給綁定過的所有隊列

隊列的消費者都能拿到消息。實現一條消息被多個消費者消費

3.4 第四種模型(Routing)

3.4.1 Routing 之訂閱模型-Direct(直連)

在Fanout模式中，一條消息，會被所有訂閱的隊列都消費。但是，在某些場景下，我們希望不同的消息被不同的隊列消費。這時就要用到Direct類型的Exchange。

在Direct模型下：

隊列與交換機的綁定，不能是任意綁定了，而是要指定一個RoutingKey（路由key）

消息的發送方在 向 Exchange發送消息時，也必須指定消息的 RoutingKey。

Exchange不再把消息交給每一個綁定的隊列，而是根據消息的Routing Key進行判斷，只有隊列的Routingkey與消息的 Routing key完全一致，才會接收到消息

3.4.2 Routing 之訂閱模型-Topic

Topic類型的Exchange與Direct相比，都是可以根據RoutingKey把消息路由到不同的隊列。只不過Topic類型Exchange可以讓隊列在綁定Routing key 的時候使用通配符！這種模型Routingkey 一般都是由一個或多個單詞組成，多個單詞之間以”.”分割，例如： item.insert

145.為什么使用rabbitmq,rabbitMq優缺點？

1.解耦（為面向服務的架構（SOA）提供基本的最終一致性實現）

2. 異步提升效率

3.?流量削峰

系統的可用性降低
系統引入的外部依賴越多，系統越容易掛掉，本來只是A系統調用BCD三個系統接口就好

ABCD四個系統不報錯整個系統會正常運行。引入了MQ之后，雖然ABCD系統沒出錯，但MQ掛了以后，整個系統也會崩潰。

系統的復雜性提高

RabbitMq

優點

1.輕量級，部署放便快捷

2.支持靈活的路由配置，可以根據配置的路由規則，讓生產者生產出來的消息發送到不同的隊列中。

3.兼容性好，RabbitMQ的客戶端支持大多數的編程語言

缺點

1.如果有大量的消息堆積在隊列中，性能會急劇下降

2.RabbitMQ是用Erlang開發的，在功能拓展和二次開發上不友好

3.對比RocketMQ和kafka，RabbitMQ性能是最差的

RocketMQ

優點

1.功能全，RocketMQ基本具備了消息隊列應有的所有功能

2.RocketMQ使用java語言開發，在進行debug源碼，擴展功能和二次開發方面都很友好

3.性能高，毫秒級響應，經受過多次雙十一的考驗

缺點

1.兼容性不好，目前只支持java和c++，但C++尚不成熟

2.社區活躍度一般

kafka

優點

1.可靠性和穩定性很高

2.性能卓越，單機吞吐量高

3.有很好的管理界面Kafka-Manager

4.日志領域非常成熟

缺點

1.消費失敗后不能重試

2.由于是異步和批處理，延遲高

3.使用短輪詢方式，實時性取決于輪詢間隔時間

正在上傳…重新上傳取消

原文鏈接：RabbitMQ筆記---對比其他MQ優缺點_求求你，別報錯了！的博客-CSDN博客_rabbitmq優缺點

146.RabbitMq交換機的類型（廣播類型）？

Rabbitmq提供的交換機類型有fanout、direct、topic、headers四種。在AMQP協議中還提到另外兩種類型：System和自定義，本次文章主要介紹一下常用的交換機的特性。

1.fanout

該類型的交換機會將一條消息廣播到綁定到該交換機的所有隊列上，不論你設置的路由鍵是什么。

正在上傳…重新上傳取消

2.direct

該類型的交換機會將綁定的路由鍵完全匹配的方式路由到指定的隊列上。如果路由鍵不匹配，那么就不會發送到任何隊列中去。

正在上傳…重新上傳取消

3.topic

該種類型的交換機會是對上述fanout和direct類型的交換機的一種擴展。其和direct很類似，但是匹配規則上有所不同。其約定的路由匹配規則有：

routingkey通過符號“.”進行分割，其分割出來的單詞就是路由的匹配元素。比如com.aa.tian這種就表示順序單詞com、aa、tian。

符號“*”和“#”分別用來進行模糊匹配，其中“*”用來表示一個單詞，“#”用來匹配多個單詞。

總結一下就是符號“*”表征一個單詞，“#”表征多個單詞。

正在上傳…重新上傳取消

4.headers

該類型的交換器不依賴路由鍵的匹配規則分發消息，而是根據發送的消息內容的headers屬性進行匹配。在綁定隊列和交換器時制定一組鍵值對，當發送消息到交換機的時候，rabbitmq會獲取該消息的headers，對比其中的鍵值對是否完全匹配隊列和交換器綁定時指定的鍵值對。如果完全匹配消息就會路由到該隊列，否則不會路由到該隊列。headers類型的交換機性能會很差，而且也不實用！

147.rabbitmq 怎么實現延遲消息隊列？

通過消息過期后進入死信交換器

再交由交換器轉發到延遲消費隊列，實現延遲功能

使用Rabbit-delayed-message-exchange插件實現延遲功能

148.rabbitmq 集群有什么用？

高可用：某個服務器出現問題，整個RabbitMq還可以繼續使用

高容量：集群可以承擔更多的消息量

149.rabbitmq 節點的類型有哪些？

磁盤節點：消息會存儲到磁盤

內存節點：消息都存儲在內存中，重啟服務器消息丟失，性能高于磁盤類型

150.rabbitmq 集群搭建需要注意哪些問題？

?各節點直接使用“--link”連接，此屬性不能忽略

?各個節點使用的erlang cookie，值必須相同，此值相當于“秘鑰”的功能，用于各個節點的認證。

整個集群必須包含一個磁盤節點

151.rabbitmq 每個節點是其他節點的完整拷貝嗎？為什么？

不是，原因有一下兩個：

存儲空間的考慮:如果每個節點都擁有所有隊列的完全拷貝

這樣新增節點不但沒有新增存儲空間，反而增加了很多冗余數據

性能的考慮：如果每條消息都需要完整的拷貝到每個集群節點

那新增節點并沒有提升處理消息的能力，最多是保持和單節點相同的性能甚至是更糟。

150.rabbitmq 集群中唯一一個磁盤節點崩潰了會發生什么情況？

如果唯一磁盤磁盤節點崩潰了，不能進行一下操作:

不能創建隊列，

不能創建交換機，

不能創建綁定，

不能添加用戶，

不能更改權限，

唯一的磁盤節點崩潰了，集群是可以保持運行的，但還是你不能更改任何東西

152.rabbitmq 對集群節點停止順序有要求嗎？

Rabbit 對集群的停止有順序要求的

應該先關閉內存節點，在關閉磁盤節點，如果順序相反的話，可能會造成消息的丟失

153.rabbitmq 死信隊列？

154.如何保證消息確定消息發送成功，并且被消費成功?

解析：這里不用背，這里的問法會有很多中，這道題中問了兩部分

第一部分是確保發送成功，還可以被問成：消息發送失敗了怎么辦，或者如何保證消息可靠傳輸

第二部分是確保消費成功，還可以被問成：消息消費時，發生異常了，消息已經被消費了，怎么辦等

首先，需要確保消息被發送成功，rabbitmq中提供了事物和confirm的機制，事物的話，就類似于數據庫的事物，開啟，執行，提交，如果過程中發生任何異常，就會觸發回滾機制，我們可以在回滾中加入一些邏輯處理，重新發送或者日志記錄，同時配置生產者確認的機制，就是在消息發送之后，該消息會被指定唯一的ID，如果有消息成功被交換機轉發到隊列之后，mq會給生產者發送ack確認，如果沒有隊列接收消息，那么會發送錯誤回執消息給生產者，生產者可以嘗試重試發送，或者日志記錄。通過這些可以看出，mq會增加一些保障性措施，必然會導致性能有一些下降，如果要保證消息的嚴格一致性，那么可以配置這些，如果消息不重要，或者允許有丟失的情況，那么可以不用配置，這樣的話能提升mq的性能。

其次就是，消息確保發送成功之后，還要確保消息被消費成功，因為在消費者端，如果消息消費時發生異常，又沒有做一些處理，那么消息就會丟失，這種情況，可以采取兩種方式解決

第一種就是消費端配置手動ACK確認機制，消息被消費完成的時候，手動確認告訴mq消費成功，mq才會刪除消息，如果消息被接收了，但是mq沒有收到ack確認，那么消息在mq中會變為unacked狀態，我們可以通過項目日志或者mq面板監控，當消費者斷開連接之后，消息會重新回到隊列中，消費者重新連接之后，會再次收到消息。

第二種就是可以結合數據庫解決，生產者端發送成功之后，可以在數據庫中存儲發送的消息和發送時間，并標記狀態為未消費狀態，消費者端消費完成之后，標記mysql中數據的狀態為已經消費。消費者端通過定時任務去數據庫跑批檢索超時未被消費的消息并重新發送，這種方式可以很好的解決消費失敗的問題，但是增加了生產者和消費者之間的耦合度，以及會造成消息重復消費的問題，我們可以在保證消息發送成功的基礎上，將上述邏輯放在消費者端，生產者正常發送消息，消費者在收到消息之后，存儲到myqsl中，標記狀態為未消費，同時ack通知mq確認，然后再消費消息，消息消費成功之后，改變mysql狀態為已消費，消費端同時配置定時任務跑批檢索數據庫，定時重新執行超時未消費的消息。

以上的解決辦法都是需要根據實際的業務需求來的，如果消息需要保證強一致性，不能出現任何差錯，那么就需要按照前面說的添加對應的配置

我們項目中的mq主要用于數據同步使用的，mysql數據發生變化之后，需要同步到es索引庫以及靜態化頁面中，這里我們配置了生產者確認模式，和消費者手動ack確認機制。

總結

以上是生活随笔為你收集整理的RabbitMQ 面试题目整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。