2021Java面試題合集-RabbitMQ面試題22道

1.什么是MQ

?MQ就是消息隊列。是軟件和軟件進(jìn)行通信的中間件產(chǎn)品

2.MQ的優(yōu)點

?簡答

。異步處理-相比于傳統(tǒng)的串行、并行方式，提高了系統(tǒng)吞吐量。

。應(yīng)用解耦-系統(tǒng)間通過消息通信，不用關(guān)心其他系統(tǒng)的處理.

。流量削鋒-可以通過消息隊列長度控制請求量；可以緩解短時間內(nèi)的高并發(fā)請求。

。日志處理-解決大量日志傳輸.

。消息通訊-消息隊列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊。比如實

現(xiàn)點對點消息隊列，或者聊天室等。

?詳答

3.解耦、異步、削峰是什么？。

?解耦：A系統(tǒng)發(fā)送數(shù)據(jù)到BCD三個系統(tǒng)，通過接口調(diào)用發(fā)送.如果E系統(tǒng)也要這個數(shù)據(jù)呢？那如

果C系統(tǒng)現(xiàn)在不需要了呢？A系統(tǒng)負(fù)責(zé)人幾乎崩潰...A系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，

A系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)，很多系統(tǒng)都需要A系統(tǒng)將這個數(shù)據(jù)發(fā)送過來.如果使用MQ,A

系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到MQ里面去，哪個系統(tǒng)需要數(shù)據(jù)自己去MQ里面消費。如果新系統(tǒng)需

要數(shù)據(jù)，直接從MQ里消費即可；如果某個系統(tǒng)不需要這條數(shù)據(jù)了，就取消對MQ消息的消費即

可。這樣下來，A系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)，不需要維護(hù)這個代碼，也不需要考慮

人家是否調(diào)用成功、失敗超時等情況。

就是一個系統(tǒng)或者一個模塊，調(diào)用了多個系統(tǒng)或者模塊，互相之間的調(diào)用很復(fù)雜，維護(hù)起來很麻煩。但是其

實這個調(diào)用是不需要直接同步調(diào)用接口的，如果用MQ給它異步化解耦。

?異步：A系統(tǒng)接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統(tǒng)寫庫，自己本地寫庫

要3ms,BCD三個系統(tǒng)分別寫庫要300ms、450ms、200ms。最終請求總延時是3+300+450

+200=953ms,接近1s,用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發(fā)起請求。

如果使用MQ,那么A系統(tǒng)連續(xù)發(fā)送3條消息到MQ隊列中，假如耗時5ms,A系統(tǒng)從接受一個

請求到返回響應(yīng)給用戶，總時長是3+5=8ms.

?削峰：減少高峰時期對服務(wù)器壓力。

4.消息隊列有什么缺點

?缺點有以下幾個：

1.系統(tǒng)可用性降低

本來系統(tǒng)運(yùn)行好好的，現(xiàn)在你非要加入個消息隊列進(jìn)去，那消息隊列掛了，你的系統(tǒng)不是呵

呵了。因此，系統(tǒng)可用性會降低；

2.系統(tǒng)復(fù)雜度提高

加入了消息隊列，要多考慮很多方面的問題，比如：一致性問題、如何保證消息不被重復(fù)消

費、如何保證消息可靠性傳輸?shù)?。因此，需要考慮的東西更多，復(fù)雜性增大。

3.一致性問題

A系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三

個系統(tǒng)那里，BD兩個系統(tǒng)寫庫成功了，結(jié)果C系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致

了。

所以消息隊列實際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方

案和架構(gòu)來規(guī)避掉，做好之后，你會發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個數(shù)量級，也許是復(fù)雜了10倍。但是關(guān)

鍵時刻，用，還是得用的。

5.你們公司生產(chǎn)環(huán)境用的是什么消息中間件？

?這個首先你可以說下你們公司選用的是什么消息中間件，比如用的是RabbitMQ,然后可以初步給

一些你對不同MQ中間件技術(shù)的選型分析。

?舉個例子：比如說ActiveMQ是老牌的消息中間件，國內(nèi)很多公司過去運(yùn)用的還是非常廣泛的，功

能很強(qiáng)大。

?但是問題在于沒法確認(rèn)ActiveMQ可以支撐互聯(lián)網(wǎng)公司的高并發(fā)、高負(fù)載以及高吞吐的復(fù)雜場景，

在國內(nèi)互聯(lián)網(wǎng)公司落地較少。而且使用較多的是一些傳統(tǒng)企業(yè)，用ActiveMQ做異步調(diào)用和系統(tǒng)解

耦。

?然后你可以說說RabbitMQ,他的好處在于可以支撐高并發(fā)、高吞吐、性能很高，同時有非常完善

便捷的后臺管理界面可以使用。

?另外，他還支持集群化、高可用部署架構(gòu)、消息高可靠支持，功能較為完善。

?而且經(jīng)過調(diào)研，國內(nèi)各大互聯(lián)網(wǎng)公司落地大規(guī)模RabbitMQ集群支撐自身業(yè)務(wù)的case較多，國內(nèi)各

種中小型互聯(lián)網(wǎng)公司使用RabbitMQ的實踐也比較多。

?除此之外，RabbitMQ的開源社區(qū)很活躍，較高頻率的迭代版本，來修復(fù)發(fā)現(xiàn)的bug以及進(jìn)行各種

優(yōu)化，因此綜合考慮過后，公司采取了RabbitMQ。

?但是RabbitMQ也有一點缺陷，就是他自身是基于erlang語言開發(fā)的，所以導(dǎo)致較為難以分析里面

的源碼，也較難進(jìn)行深層次的源碼定制和改造，畢竟需要較為扎實的edang語言功底才可以。

?然后可以聊聊RocketMQ,是阿里開源的，經(jīng)過阿里的生產(chǎn)環(huán)境的超高并發(fā)、高吞吐的考驗，性能

卓越，同時還支持分布式事務(wù)等特殊場景。

?而且RocketMQ是基于Java語言開發(fā)的，適合深入閱讀源碼，有需要可以站在源碼層面解決線上生

產(chǎn)問題，包括源碼的二次開發(fā)和改造。

?另外就是Kafka。Kafka提供的消息中間件的功能明顯較少一些，相對上述幾款MQ中間件要少很

多。

?但是Kafka的優(yōu)勢在于專為超高吞吐量的實時日志采集、實時數(shù)據(jù)同步、實時數(shù)據(jù)計算等場景來設(shè)

計。

?因此Kafka在大數(shù)據(jù)領(lǐng)域中配合實時計算技術(shù)（比如SparkStreaming、Storm、Flink）使用的較

多.但是在傳統(tǒng)的MQ中間件使用場景中較少采用。

6.Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么

優(yōu)缺點？

ActiveMQRabbitMQRocketMQKafka

萬級，比

單機(jī)10萬級，高吞吐，一般配合大數(shù)據(jù)類的

RocketMQ、同

吞吐10萬級，支撐高吞吐系統(tǒng)來進(jìn)行實時數(shù)據(jù)計算、日志采集等場

KafkaActiveMQ

景

數(shù)量級

topic

topic可以達(dá)到幾百/幾千的級

數(shù)量topic從幾十到幾百個時候，吞吐量會大

別，吞吐量會有較小幅度的下

對吞幅度下降，在同等機(jī)器下，Kafka盡量保

降，這是RocketMQ的一大優(yōu)

證topic數(shù)量不要過多，如果要支撐大規(guī)

勢，在同等機(jī)器下，可以支撐大

的影模的topic,需要增加更多的機(jī)翡資源

量的topic

響

微秒級，這

是

時效RabbitMQ

ms級ms級延遲在ms級以內(nèi)

性的一大特

點，延遲最

低

高，基于主非常高，分布式,一個數(shù)據(jù)多個副本，少

可用同

從架構(gòu)實現(xiàn)非常高，分布式架構(gòu)數(shù)機(jī)器宕機(jī)，不會丟失數(shù)據(jù)，不會導(dǎo)致不

性ActiveMQ

高可用可用

消息

有較低的概經(jīng)過參數(shù)優(yōu)化配置，可以做到0

可靠*桎同RocketMQ

率丟失數(shù)據(jù)丟失

性

基于erlang

MQ領(lǐng)域的開發(fā)，并發(fā)功能較為簡單，主要支持簡單的MQ功

功能MQ功能較為完善，還是分布式

功能極其完能力很強(qiáng).能，在根據(jù)領(lǐng)域的實時計算以及日志采

支持的，擴(kuò)展性好

備性能極好.集被大規(guī)模使用

延時很低

?綜上，各種對比之后，有如下建議：

?一般的業(yè)務(wù)系統(tǒng)要引入MQ,最早大家都用ActiveMQ,但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大

規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；

?后來大家開始用RabbitMQ,但是確實erlang語言阻止了大量的Java工程師去深入研究和掌控

它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也

局；

?不過現(xiàn)在確實越來越多的公司會去用RocketMQ,確實很不錯，畢竟是阿里出品，但社區(qū)可能有

突然黃掉的風(fēng)險（目前RocketMQ已捐給但GitHub上的活躍度其實不算高）對自己公

司技術(shù)實力有絕對自信的，推薦用RocketMQ,否則回去老老實實用RabbitMQ吧，人家有活躍

的開源社區(qū)，絕對不會黃.

?所以中小型公司，技術(shù)實力較為一般，技術(shù)挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型

公司，基礎(chǔ)架構(gòu)研發(fā)實力較強(qiáng)，用RocketMQ是很好的選擇。

?如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對沒問題，社區(qū)活

躍度很高，絕對不會黃，何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范。

7.MQ有哪些常見問題？如何解決這些問題?

?MQ的常見問題有：

。消息的順序問題

。消息的重復(fù)問題

消息的順序問題

?消息有序指的是可以按照消息的發(fā)送順序來消費。

?假如生產(chǎn)者產(chǎn)生了2條消息：M1、M2,假定M1發(fā)送到S1,M2發(fā)送至！JS2,如果要保證M1先

于M2被消費，怎么做？

?解決方案：

1.保證生產(chǎn)者-MQServer-消費者是一對一對一的關(guān)系

M速群消費者集群

時在*,先發(fā)送

?缺陷：

。并行度就會成為消息系統(tǒng)的瓶頸（吞吐量不夠）

。更多的異常處理，比如：只要消費端出現(xiàn)問題，就會導(dǎo)致整個處理流程阻塞，我們不得不花

費更多的精力來解決阻塞的問題。（2）通過合理的設(shè)計或者將問題分解來規(guī)避。

。不關(guān)注亂序的應(yīng)用實際大量存在

。隊列無序并不意味著消息無序所以從業(yè)務(wù)層面來保證消息的順序而不僅僅是依賴于消息系

統(tǒng)，是一種更合理的方式。

消息的重復(fù)問題

?造成消息重復(fù)的根本原因是：網(wǎng)絡(luò)不可達(dá)。

?所以解決這個問題的辦法就是繞過這個問題。那么問題就變成了：如果消費端收到兩條一樣的消

息，應(yīng)該怎樣處理？

?消費端處理消息的業(yè)務(wù)邏輯保持鬲等性。只要保持鬲等性，不管來多少條重復(fù)消息，最后處理的結(jié)

果都一樣。保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現(xiàn)。利用一張日

志表來記錄已經(jīng)處理成功的消息的ID,如果新到的消息ID已經(jīng)在日志表中，那么就不再處理這條

消息。

8.什么是RabbitMQ?

?RabbitMQ是一款開源的，Erlang編寫的，消息中間件；最大的特點就是消費并不需要確保提供方

存在,實現(xiàn)了服務(wù)之間的高度解耦可以用它來：解耦、異步、削峰。

9.rabbitmq的使用場景

(1)服務(wù)間異步通信

(2)順序消費

(3)定時任務(wù)

(4)請求削峰

10.RabbitMQ基本概念

?Broker:簡單來說就是消息隊列服務(wù)器實體

?Exchange:消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個隊列

?Queue:消息隊列載體，每個消息都會被投入到一個或多個隊列

?Binding:綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來

?RoutingKey:路由關(guān)鍵字，exchange根據(jù)這個關(guān)鍵字進(jìn)行消息投遞

?VHost:vhost可以理解為虛擬broker,即mini-RabbitMQserver。其內(nèi)部均含有獨立的

queue,exchange和binding等，但最最重要的是，其擁有獨立的權(quán)限系統(tǒng)，可以做到vhost范

圍的用戶控制.當(dāng)然，從RabbitMQ的全局角度，vhost可以作為不同權(quán)限隔離的手段(一個典

型的例子就是不同的應(yīng)用可以跑在不同的vhost中)。

?Producer:消息生產(chǎn)者，就是投遞消息的程序

?Consumer:消息消費者，就是接受消息的程序

?Channel:消息通道，在客戶端的每個連接里，可建立多個channel,每個channel代表一個會話

任務(wù)

由Exchange、Queue、RoutingKey三個才能決定一個從Exchange到Queue的唯一的線路。

11.RabbitMQ的工作模式

一.simple模式(即最簡單的收發(fā)模式)

1.消息產(chǎn)生消息，將消息放入隊列

2.消息的消費者（consumer）監(jiān)聽消息隊列，如果隊列中有消息，就消費掉，消息被拿走后,自動從隊列中

刪除（隱患消息可能沒有被消費者正確處理,已經(jīng)從隊列中消失了，造成消息的丟失，這里可以設(shè)置

成手動的ack,但如果設(shè)置成手動ack,處理完后要及時發(fā)送ack消息給隊列，否則會造成內(nèi)存溢

出）。

二.work工作模式（資源的競爭）

1.消息產(chǎn)生者將消息放入隊列消費者可以有多個消費者1,消費者2同時監(jiān)聽同f隊列消息被消費。

C1C2共同爭搶當(dāng)前的消息隊列內(nèi)容，誰先拿到誰負(fù)責(zé)消費消息（隱患：高并發(fā)情況下，默認(rèn)會產(chǎn)生某

一個消息被多個消費者共同使用，可以設(shè)置一個開關(guān)（syncronize）保證一條消息只能被一個消費者

使用）。

三.publish/subscribe發(fā)布訂閱（共享資源）

amq.gen-RQ6...

1.每個消費者監(jiān)聽自己的隊列；

2.生產(chǎn)者將消息發(fā)給broker,由交換機(jī)將消息轉(zhuǎn)發(fā)到綁定此交換機(jī)的每個隊列，每個綁定交換機(jī)的

隊列都將接收到消息。

四.routing路由模式

Q1

1.消息生產(chǎn)者將消息發(fā)送給交換機(jī)按照路由判斷,路由是字符串（inf。）當(dāng)前產(chǎn)生的消息攜帶路由字符

（對象的方法），交換機(jī)根據(jù)路由的key,只能匹配上路由key對應(yīng)的消息隊列，對應(yīng)的消費者才能消費消

2.根據(jù)業(yè)務(wù)功能定義路由字符串

3.從系統(tǒng)的代碼邏輯中獲取對應(yīng)的功能字符串，將消息任務(wù)扔到對應(yīng)的隊列中。

4.業(yè)務(wù)場景:error通知;EXCEPTION;錯誤通知的功能;傳統(tǒng)意義的錯誤通知;客戶通知;利用key路由，可

以將程序中的錯誤封裝成消息傳入到消息隊列中，開發(fā)者可以自定義消費者，實時接收錯誤；

五.topic主題模式（路由模式的一種）

Q1

1.星號井號代表通配符

2.星號代表多個單詞，井號代表一個單詞

3.路由功能添加模糊匹配

4.消息產(chǎn)生者產(chǎn)生消息，把消息交給交換機(jī)

5.交換機(jī)根據(jù)key的規(guī)則模糊匹配到對應(yīng)的隊列,由隊列的監(jiān)聽消費者接收消息消費

（在我的理解看來就是routing查詢的一種模糊匹配，就類似sql的模糊查詢方式）

12.如何保證RabbitMQ消息的順序性？

?拆分多個queue（消息隊列），每個queue（消息隊列）—f?consumer（消費者），就是多一些queue

（消息隊列）而已，確實是麻煩點；

?或者就一個queue（消息隊列）但是對應(yīng)一個consumer（消費者），然后這個consumer（消費者）內(nèi)

部用內(nèi)存隊列做排隊，然后分發(fā)給底層不同的worker來處理。

13.消息如何分發(fā)？

?若該隊列至少有一個消費者訂閱，消息將以循環(huán)（round-robin）的方式發(fā)送給消費者。每條消息

只會分發(fā)給一個訂閱的消費者（前提是消費者能夠正常處理消息并進(jìn)行確認(rèn)）。通過路由可實現(xiàn)多

消費的功能

14.消息怎么路由？

?消息提供方，路由-＞一至多個隊列消息發(fā)布到交換器時，消息將擁有一個路由鍵（routingkey）,

在消息創(chuàng)建時設(shè)定。通過隊列路由鍵，可以把隊列綁定到交換器上。消息到達(dá)交換器后，

RabbitMQ會將消息的路由鍵與隊列的路由健進(jìn)行匹配（針對不同的交換器有不同的路由規(guī)則）；

?常用的交換器主要分為一下三種：

1.fanout:如果交換器收到消息，將會廣播到所有綁定的隊列上

2.direct:如果路由健完全匹配，消息就被投遞到相應(yīng)的隊列

3.topic:可以使來自不同源頭的消息能夠到達(dá)同f隊列。使用topic交換器時，可以使用通

配符

15.消息基于什么傳輸？

?由于TCP連接的創(chuàng)建和銷毀開銷較大，且并發(fā)數(shù)受系統(tǒng)資源限制，會造成性能瓶頸。RabbitMQ

使用信道的方式來傳輸數(shù)據(jù)。信道是建立在真實的TCP連接內(nèi)的虛擬連接，且每條TCP連接上的

信道數(shù)量沒有限制。

16.如何保證消息不被重復(fù)消費？或者說，如何保證消息消

費時的幕等性？

?先說為什么會重復(fù)消費：正常情況下，消費者在消費消息的時候，消費完畢后，會發(fā)送一個確認(rèn)消

息給消息隊列，消息隊列就知道該消息被消費了，就會將該消息從消息隊列中刪除；

?但是因為網(wǎng)絡(luò)傳輸?shù)鹊裙收希_認(rèn)信息沒有傳送到消息隊列，導(dǎo)致消息隊列不知道自己已經(jīng)消費過

該消息了，再次將消息分發(fā)給其他的消費者。

?針對以上問題，一個解決思路是：保證消息的唯一性，就算是多次傳輸，不要讓消息的多次消費帶

來影響；保證消息等幕性；

。比如：在寫入消息隊列的數(shù)據(jù)做唯一標(biāo)示，消費消息時，根據(jù)唯一標(biāo)識判斷是否消費過；

。假設(shè)你有個系統(tǒng)，消費一條消息就往數(shù)據(jù)庫里插入一條數(shù)據(jù)，要是你一個消息重復(fù)兩次，你

不就插入了兩條，這數(shù)據(jù)不就錯了？但是你要是消費到第二次的時候，自己判斷一下是否已

經(jīng)消費過了，若是就直接扔了，這樣不就保留了一條數(shù)據(jù)，從而保證了數(shù)據(jù)的正確性。

17.如何確保消息正確地發(fā)送至RabbitMQ?如何確保消

息接收方消費了消息？

發(fā)送方確認(rèn)模式

?將信道設(shè)置成confirm模式（發(fā)送方確認(rèn)模式），則所有在信道上發(fā)布的消息都會被指派一個唯

一的ID。

?一旦消息被投遞到目的隊列后，或者消息被寫入磁盤后（可持久化的消息），信道會發(fā)送一個確認(rèn)

給生產(chǎn)者（包含消息唯一ID）。

?如果RabbitMQ發(fā)生內(nèi)部錯誤從而導(dǎo)致消息丟失，會發(fā)送一條nack（notacknowledged,未確

認(rèn)）消息。

?發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時，可以繼續(xù)發(fā)送消息。當(dāng)確認(rèn)消息到

達(dá)生產(chǎn)者應(yīng)用程序，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會被觸發(fā)來處理確認(rèn)消息。

接收方確認(rèn)機(jī)制

?消費者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個不同操作）。只有消費者確

認(rèn)了消息，RabbitMQ才能安全地把消息從隊列中刪除。

?這里并沒有用到超時機(jī)制，RabbitMQ僅通過Consumer的連接中斷來確認(rèn)是否需要重新發(fā)送消

息。也就是說，只要連接不中斷，RabbitMQ給了Consumer足夠長的時間來處理消息。保證數(shù)

據(jù)的最終一致性；

下面羅列幾種特殊情況

?如果消費者接收到消息，在確認(rèn)之前斷開了連接或取消訂閱，RabbitMQ會認(rèn)為消息沒有被分發(fā)，

然后重新分發(fā)給下一個訂閱的消費者。（可能存在消息重復(fù)消費的隱患，需要去重）

?如果消費者接收到消息卻沒有確認(rèn)消息，連接也未斷開，則RabbitMQ認(rèn)為該消費者繁忙，將不

會給該消費者分發(fā)更多的消息。

18.如何保證RabbitMQ消息的可靠傳輸？

?消息不可靠的情況可能是消息丟失，劫持等原因；

?丟失又分為：生產(chǎn)者丟失消息、消息列表丟失消息、消費者丟失消息；

1.生產(chǎn)者丟失消息：從生產(chǎn)者弄丟數(shù)據(jù)這個角度來看，RabbitMQ提供transaction和confirm模式來

確保生產(chǎn)者不丟消息；

transaction機(jī)制就是說：發(fā)送消息前，開啟事務(wù)（channel.txSelectQ），然后發(fā)送消息，如果發(fā)送

過程中出現(xiàn)什么異常，事務(wù)就會回滾（channel.txRollback。），如果發(fā)送成功則提交事務(wù)

（channel.txCommitO）。然而，這種方式有個缺點：吞吐量下降；

confirm模式用的居多：一旦channel進(jìn)入confirm模式，所有在該信道上發(fā)布的消息都將會被指派

一個唯一的ID（從1開始），一旦消息被投遞到所有匹配的隊列之后；

rabbitMQ就會發(fā)送一個ACK給生產(chǎn)者（包含消息的唯一ID）,這就使得生產(chǎn)者知道消息已經(jīng)正確

到達(dá)目的隊列了；

如果rabbitMQ沒能處理該消息，則會發(fā)送一個Nack消息給你，你可以進(jìn)行重試操作。

2.消息隊列丟數(shù)據(jù)：消息持久化。

處理消息隊列丟數(shù)據(jù)的情況，一般是開啟持久化磁盤的配置。

這個持久化配置可以和confirm機(jī)制配合使用，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個

Ack信號。

這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那么生產(chǎn)者收不到Ack信號，生產(chǎn)者會自動

重發(fā)。

那么如何持久化呢？

這里K便說一下吧，其實也很容易，就下面兩步

1.將queue的持久化標(biāo)識durable設(shè)置為true,則代表是一個持久的隊列

2.發(fā)送消息的時候?qū)eliveryMode=2

這樣設(shè)置以后，即使rabbitMQ掛了，重啟后也能恢復(fù)數(shù)據(jù)

3.消費者丟失消息：消費者丟數(shù)據(jù)一般是因為采用了自動確認(rèn)消息模式，改為手動確認(rèn)消息即可！

消費者在收到消息之后，處理消息之前，會自動回復(fù)RabbitMQ已收到消息；

如果這時處理消息失敗，就會丟失該消息；

解決方案：處理消息成功后，手動回復(fù)確認(rèn)消息。

19.為什么不應(yīng)該對所有的message都使用持久化機(jī)制？

?首先，必然導(dǎo)致性能的下降，因為寫磁盤比寫RAM慢的多，message的吞吐量可能有10倍的差

距。

?其次，message的持久化機(jī)制用在RabbitMQ的內(nèi)置cluster方案時會出現(xiàn)“坑爹”問題。矛盾點在

于，若message設(shè)置了persistent屬性，但queue未設(shè)置durable屬性，那么當(dāng)該queue的

ownernode出現(xiàn)異常后，在未重建該queue前，發(fā)往該queue的message將被blackholed

；若message設(shè)置了persistent屬性，同時queue也設(shè)置了durable屬性，那么當(dāng)queue的

ownernode異常且無法重啟的情況下，則該queue無法在其他node上重建，只能等待其

ownernode重啟后，才能恢復(fù)該queue的使用，而在這段時間內(nèi)發(fā)送給該queue的message

將被blackholed。

?所以，是否要對message進(jìn)行持久化，需要綜合考慮性能需要，以及可能遇到的問題。若想達(dá)到

100,000條/秒以上的消息吞吐量（單RabbitMQ服務(wù)器），則要么使用其他的方式來確保

message的可靠delivery,要么使用非常快速的存儲系統(tǒng)以支持全持久化（例如使用SSD）o另

外一種處理原則是：僅對關(guān)鍵消息作持久化處理（根據(jù)業(yè)務(wù)重要程度），且應(yīng)該保證關(guān)鍵消息的量

不會導(dǎo)致性能瓶頸。

20.如何保證高可用的？RabbitMQ的集群

?RabbitMQ是比較有代表性的，因為是基于主從（非分布式）做高可用性的，我們就以RabbitMQ

為例子講解第一種MQ的高可用性怎么實現(xiàn)。RabbitMQ有三種模式：單機(jī)模式、普通集群模

式、鏡像集群模式。

1.單機(jī)模式，就是Dem。級別的，一般就是你本地啟動了玩玩兒的?，沒人生產(chǎn)用單機(jī)模式

2.普通集群模式：

。意思就是在多臺機(jī)器上啟動多個RabbitMQ實例，每個機(jī)器啟動一個。

。你創(chuàng)建的queue,只會放在一個RabbitMQ實例上，但是每個實例都同步queue的元數(shù)據(jù)

（元數(shù)據(jù)可以認(rèn)為是queue的一些配置信息，通過元數(shù)據(jù)，可以找到queue所在實例）。

你消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從queue所在實例上拉

取數(shù)據(jù)過來。這方案主要是提高吞吐量的，就是說讓集群中多個節(jié)點來服務(wù)某個queue的讀

寫操作。

3.鏡像集群模式：

。這種模式，才是所謂的RabbitMQ的高可用模式。跟普通集群模式不一樣的是，在鏡像集群

模式下，你創(chuàng)建的queue,無論元數(shù)據(jù)還是queue里的消息都會存在于多個實例上，就是

說，每個RabbitMQ節(jié)點都有這個queue的一個完整鏡像，包含queue的全部數(shù)據(jù)的意

思。然后每次你寫消息到queue的時候，都會自動把消息同步到多個實例的queue上。

RabbitMQ有很好的管理控制臺，就是在后臺新增一個策略，這個策略是鏡像集群模式的策

略，指定的時候是可以要求數(shù)據(jù)同步到所有節(jié)點的，也可以要求同步到指定數(shù)量的節(jié)點，再

次創(chuàng)建queue的時候，應(yīng)用這個策略，就會自動將數(shù)據(jù)同步到其他的節(jié)點上去了.

。這樣的好處在于，你任何一個機(jī)器宕機(jī)了，沒事兒，其它機(jī)器（節(jié)點）還包含了這個queue

的完整數(shù)據(jù)，別的consumer都可以到其它節(jié)點上去消費數(shù)據(jù)。壞處在于，第一，這個性能

開銷也太大了吧，消息需要同步到所有機(jī)器上，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！RabbitMQ

一個queue的數(shù)據(jù)都是放在一個節(jié)點里的，鏡像集群下，也是每個節(jié)點都放這個queue的

完整數(shù)據(jù)。

21.如何解決消息隊列的延時以及過期失效問題？消息隊列

滿了以后該怎么處理？有幾百萬消息持續(xù)積壓幾小時，怎

么辦？

?消息積壓處理辦法：臨時緊急擴(kuò)容：

?先修復(fù)consumer的問題，確保其恢復(fù)消費速度，然后將現(xiàn)有cnosumer都停掉。

新建一個topic,partition是原來的10倍，臨時建立好原先10倍的queue數(shù)量。

然后寫一個臨時的分發(fā)數(shù)據(jù)的consumer程序，這個程序部署上去消費積壓的數(shù)據(jù)，