?

開篇介紹

大家好，公眾號【Java極客思維】近期會整理一些Java高頻面試題分享給小伙伴，也希望看到的小伙伴在找工作過程中能夠用得到！本章節主要針對Java一些消息中間件高頻面試題進行分享。

通知：公眾號【Java極客思維】正在送書福利活動，關注公眾號并參加福利活動吧！只有參與了本次活動的小伙伴才能夠參與年底的大福利，不要錯過呀~

Q1：

RabbitMQ 的介紹、用途、好處？

RabbitMQ是一款開源的，Erlang編寫的，基于AMQP協議的消息中間件。

作用：解耦?、?異步?、?削峰?。

優點：解耦、異步、削峰；

缺點：降低了系統的穩定性：系統中使用了消息隊列，如果消息隊列掛了，那么系統也會掛。降低了系統可用性。

加入消息隊列，要考慮很多方面的問題，比如：一致性問題 、如何保證消息不被重復消費 、?如何保證消息可靠性傳輸 等。因此考慮的因素有很多方面，復雜性增加。

Q2：

RabbitMQ 包括哪些要素？生產者?：消息的創建者，發送到RabbitMQ

消費者?：連接到RabbitMQ，訂閱到隊列上，消費消息，持續訂閱(basicConsumer)和單條訂閱(basicGet)

消息 ：包含有效載荷和標簽，有效載荷指要傳輸的數據，標簽描述了有效載荷，并且RabbitMQ用它來決定誰獲得消息，消費者只能拿到有效載荷，并不知道生產者是誰。

Q3：

RabbitMQ 什么是信道？

信道：是生產者、消費者與RabbitMQ通信的渠道，生產者publish或是消費者subscribe一個隊列都是通過信道來通信的。信道是建立在TCP連接上的虛擬連接。就是說RabbitMQ在一條TCP上建立成百上千個信道來達到多個線程處理，這個TCP被多個線程共享，每個線程對應一個信道，信道在RabbitMQ都有一個唯一的ID，保證了信道私有性，對應上唯一的線程使用。

疑問：為什么不建立多個TCP連接？

原因是RabbitMQ需要保證性能，系統為每個線程開辟一個TCP是非常消耗性能的，美妙成百上千的建立銷毀TCP會嚴重消耗系統性能；所以RabbitMQ選擇建立多個信道(建立在TCP的虛擬連接)連接到RabbitMQ上

Q4：

RabbitMQ概念里的channel、exchange 和 queue是邏輯概念，還是對應著進程實體？作用分別是什么？

queue?具有自己的?erlang?進程；

exchange?內部實現為保存?binding?關系的查找表；

channel?是實際進行路由工作的實體，負責按照 routing_key 將 message投遞給queue。

由 AMQP 協議描述可知，channel?是真實TCP連接之上的?虛擬連接?， 所有AMQP 命令都是通過 channel 發送的，且每一個 channel 有?唯一的ID?。一個 channel 只能被單獨一個操作系統線程使用，所以投遞到特定的 channel 上的 message 是有順序的。單一個操作系統線程上允許使用多個channel。

Q5：

RabbitMQ消息是如何路由的？

消息路由必須有三部分：交換器、路由、綁定。

生產者把消息發布到交換器上，綁定決定了消息如何從路由器路由到特定的隊列；消息最終到達隊列，并被消費者接收。

消息發布到交換器時，消息將擁有一個?路由鍵(routing key)?， 在消息創建時設定。

通過隊列路由鍵，可以把隊列綁定到交換器上。

消息到達交換器后，RabbitMQ會將消息的路由鍵與隊列的路由鍵進行匹配(針對不同的交換器有不同的路由規則)。如果能夠匹配到隊列，則消息會投遞到相應隊列中；如果不能匹配到任何隊列，消息將進入"黑洞"。

常用的交換器主要分為以下三種：direct?：如果路由鍵完全匹配，消息就會被投遞到相應的隊列；每個AMQP的實現都必須有一個direct交換器，包含一個空白字符串名稱的默認交換器。聲明一個隊列時，會自動綁定到默認交換器，并且以隊列名稱作為路由鍵：channel -> basic_public($msg, '', 'queue-name')

fanout?：?如果交換器收到消息，將會廣播到所有綁定的隊列上；

topic?：可以使來自不同源頭的消息能夠到達同一個隊列。使用topic交換器時，可以使用通配符，比如："*"?匹配特定位置的任意文本，"."?把路由鍵分為了幾個標識符，?"#"?匹配所有規則等。

特別注意：發往topic交換器的消息不能隨意的設置選擇鍵(routing_key)，必須是有"."隔開的一系列的標識符組成。

Q6：

RabbitMQ消息確認過程？

消費者收到的每一條消息都必須進行確認(自動確認和自行確認)

消費者在聲明隊列時，可以置頂autoAck參數，當autoAck = false時，RabbitMQ會等待消費者顯式發送回 ack 信號后才從內存(和磁盤，如果是持久化消息的話)中刪除消息，否則RabbitMQ會在隊列中消息被消費后立即刪除它。

采用消息確認機制后，只要使 autoAck = false，消費者就有足夠的時間處理消息(任務)，不用擔心處理消息過程中消費者進程掛掉后消息丟失的問題，因為RabbitMQ會一直持有消息直到消費者顯式調用basicAck為止。

當autoAck = false時，對于RabbitMQ服務器端而言，隊列中的消息分成了兩部分：一部分是等待投遞給消費者的消息；一部分是已經投遞給消費者，但是還沒有收到消費者ack信號的消息。如果服務器端一直沒有收到消費者的ack信號，并且消費此消息的消費者已經斷開連接，則服務器端會安排該消息 重新進入隊列，等待投遞給下一個消費者(也可能還是原來的那個消費者)。

RabbitMQ不會為 ack消息設置超時時間，它判斷此消息是否需要重新投遞給消費者的唯一依據是消費該消息的消費者連接是否已經斷開。這么設計的原因是RabbitMQ允許消費者消費一條消息的時間可以很久很久。

Q7：

如何保證RabbitMQ不被重復消費？

正常情況下，消費者在消費消息的時候，消費完畢后，會發送一個確認信息給消息隊列，消息隊列就知道該消息被消費了，就會將該消息從消息隊列中刪除。

但是因為網絡傳輸等故障，確認信息沒有傳送到消息隊列，導致消息隊列不知道自己已經消費過該消息了，再次將消息分發給其他的消費者。

解決思路：

保證消息的唯一性，就算是多次傳輸，不要讓消息的多次消費帶來影響；

保證消息冪等性；

比如：在寫入消息隊列的數據做唯一標識，消費消息時，根據唯一標識判斷該消息是否被消費過。

Q8：

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

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

丟失可能又分為：生產者丟失消息

消息隊列丟失消息

消費者丟失消息

生產者丟失消息：

從生產者弄丟數據來看，RabbitMQ提供了?transaction?機制 和?confirm 模式 來確保生產者不丟失消息；transaction機制：?發送消息前，開啟事務(channel.exSelect())，然后發送消息，如果發送過程中出現異常，事務就會回滾(channel.txRollback())，如果發送成功則提交事務(channel.txCommit())。

confirm模式：一般這種模式居多，一旦channel進入confirm模式，所有在該信道上發布的消息都將會被指派一個唯一的ID(從1開始)，一旦消息被投遞到所有匹配的隊列后；RabbitMQ就會發送一個ACK給生產者(包含消息的唯一ID)，這就使得生產者知道消息已經正確到達目的隊列了。

如果RabbitMQ沒能處理該消息，則會發送一個Nack消息回來，這樣可以進行重試操作。

消息隊列丟失消息：

針對消息隊列丟失數據的情況，一般是開啟持久化磁盤的配置：

將隊列的持久化標識?durable?設置為?true?， 則代表是一個持久的隊列，發送消息的時候講?deliveryMode=2?這樣設置以后，即使RabbitMQ掛了，重啟后也能恢復數據。

消費者丟失消息：

消費者丟失消息一般是因為采用了自動確認消息模式，改為手動確認消息即可。

消費者在收到消息之后，處理消息之前，會自動回復RabbitMQ已收到消息；如果這時候處理消息失敗，就會丟失該消息；

解決方案：處理消息成功后，手動回復確認消息。

點關注、不迷路

如果覺得文章不錯，歡迎關注、點贊、收藏，你們的支持是我創作的動力，感謝大家。

如果文章寫的有問題，請不要吝嗇，歡迎留言指出，我會及時核查修改。

如果你還想更加深入的了解我，可以微信搜索「Java極客思維」進行關注。每天8:00準時推送技術文章，讓你的上班路不在孤獨，而且每月還有送書活動，助你提升硬實力！查看原文