問題一：RabbitMQ 中的 broker 是指什麼？cluster 又是指什麼？
答：broker 是指一個或多個 erlang node 的邏輯分組，且 node 上運行着 RabbitMQ 應用
程序。cluster 是在 broker 的基礎之上，增加了 node 之間共享元數據的約束。
問題二：什麼是元數據？元數據分爲哪些類型？包括哪些內容？與 cluster 相關的元數據 有哪些？元數據是如何保存的？元數據在 cluster 中是如何分佈的？
答：在非 cluster 模式下，元數據主要分爲 Queue 元數據（queue 名字和屬性等）、 Exchange 元數據（exchange 名字、類型和屬性等）、Binding 元數據（存放路由關係的查 找表）、Vhost元數據（vhost 範圍內針對前三者的名字空間約束和安全屬性設置）。在 cluster 模式下，還包括 cluster 中 node 位置信息和 node 關係信息。元數據按照 erlang node 的類型確定是僅保存於 RAM 中，還是同時保存在 RAM 和 disk 上。元數據在 cluster 中是全 node 分佈的。
問題三：RAM node 和 disk node 的區別？
答：RAM node 僅將 fabric（即 queue、exchange 和 binding 等 RabbitMQ 基礎構件）相關元數據保存到內存中，但 disk node 會在內存和磁盤中均進行存儲。RAM node 上唯一 會存儲到磁盤上的元數據是 cluster 中使用的 disk node 的地址。要求在 RabbitMQ cluster 中至少存在一個 disk node 。
問題四：RabbitMQ 上的一個 queue 中存放的 message 是否有數量限制？
答：可以認爲是無限制，因爲限制取決於機器的內存，但是消息過多會導致處理效率的下
降。
問題五：RabbitMQ 概念裏的 channel、exchange 和 queue 這些東東是邏輯概念，還是對應着進程實體？這些東東分別起什麼作用？
答：queue 具有自己的 erlang 進程；exchange 內部實現爲保存 binding 關係的查找表； channel 是實際進行路由工作的實體，即負責按照 routing_key 將 message 投遞給 queue 。由 AMQP 協議描述可知，channel 是真實 TCP 連接之上的虛擬連接，所有
AMQP 命令都是通過 channel 發送的，且每一個 channel 有唯一的 ID。一個 channel 只能被單獨一個操作系統線程使用，故投遞到特定 channel 上的 message 是有順序的。但一個操作系統線程上允許使用多個 channel 。channel 號爲 0 的 channel 用於處理所有 對於當前 connection 全局有效的幀，而 1-65535 號 channel 用於處理和特定 channel 相 關的幀。
問題六：vhost 是什麼？起什麼作用？
答：vhost 可以理解爲虛擬 broker ，即 mini-RabbitMQ server。其內部均含有獨立的queue、exchange 和 binding 等，但最最重要的是，其擁有獨立的權限系統，可以做到 vhost 範圍的用戶控制。當然，從 RabbitMQ 的全局角度，vhost 可以作爲不同權限隔離 的手段（一個典型的例子就是不同的應用可以跑在不同的 vhost 中）。
問題七：在單 node 系統和多 node 構成的 cluster 系統中聲明 queue、exchange ，以及進行 binding 會有什麼不同？
答：當你在單 node 上聲明 queue 時，只要該 node 上相關元數據進行了變更，你就會 得到 Queue.Declare-ok 迴應；而在 cluster 上聲明 queue ，則要求 cluster 上的全部 node 都要進行元數據成功更新，纔會得到 Queue.Declare-ok 迴應。另外，若 node 類型 爲 RAM node 則變更的數據僅保存在內存中，若類型爲 disk node 則還要變更保存在磁盤 上的數據。
問題八：客戶端連接到 cluster 中的任意 node 上是否都能正常工作？
答：是的。客戶端感覺不到有何不同。
問題九：若 cluster 中擁有某個 queue 的 owner node 失效了，且該 queue 被聲明具有durable 屬性，是否能夠成功從其他 node 上重新聲明該 queue ？
答：不能，在這種情況下，將得到 404 NOT_FOUND 錯誤。只能等 queue 所屬的 node 恢復後才能使用該 queue 。但若該 queue 本身不具有 durable 屬性，則可在其他 node上重新聲明。
問題十：cluster 中 node 的失效會對 consumer 產生什麼影響？若是在 cluster 中創建了mirrored queue ，這時 node 失效會對 consumer 產生什麼影響？
答：若是 consumer 所連接的那個 node 失效（無論該 node 是否爲 consumer 所訂閱 queue 的 owner node），則 consumer 會在發現 TCP 連接斷開時，按標準行爲執行重連 邏輯，並根據“Assume Nothing”原則重建相應的 fabric 即可。若是失效的 node 爲 consumer 訂閱 queue 的 owner node，則 consumer 只能通過 Consumer Cancellation Notification 機制來檢測與該 queue 訂閱關係的終止，否則會出現傻等卻沒有任何消息來 到的問題。
問題十一：能夠在地理上分開的不同數據中心使用 RabbitMQ cluster 麼？
答：不能。第一，你無法控制所創建的 queue 實際分佈在 cluster 裏的哪個 node 上（一 般使用 HAProxy + cluster 模型時都是這樣），這可能會導致各種跨地域訪問時的常見問 題；第二，Erlang 的 OTP 通信框架對延遲的容忍度有限，這可能會觸發各種超時，導致 業務疲於處理；第三，在廣域網上的連接失效問題將導致經典的“腦裂”問題，而 RabbitMQ 目前無法處理（該問題主要是說 Mnesia）。
問題十二：爲什麼 heavy RPC 的使用場景下不建議採用 disk node ？
答：heavy RPC 是指在業務邏輯中高頻調用 RabbitMQ 提供的 RPC 機制，導致不斷創建、 銷燬 reply queue ，進而造成 disk node 的性能問題（因爲會針對元數據不斷寫盤）。所以 在使用 RPC 機制時需要考慮自身的業務場景。
問題十三：向不存在的 exchange 發 publish 消息會發生什麼？向不存在的 queue 執行consume 動作會發生什麼？
問題十四：routing_key 和 binding_key 的最大長度是多少？
問題十五：RabbitMQ 允許發送的 message 最大可達多大？
問題十六：什麼情況下 producer 不主動創建 queue 是安全的？
問題十七：“dead letter”queue 的用途？
問題十八：爲什麼說保證 message 被可靠持久化的條件是 queue 和 exchange 具有durable 屬性，同時 message 具有 persistent 屬性纔行？
問題十九：什麼情況下會出現 blackholed 問題？
問題二十：如何防止出現 blackholed 問題？
問題二十一：Consumer Cancellation Notification 機制用於什麼場景？
問題二十二：Basic.Reject 的用法是什麼？
問題二十三：爲什麼不應該對所有的 message 都使用持久化機制？
問題二十四：RabbitMQ 中的 cluster、mirrored queue，以及 warrens 機制分別用於解決什麼問題？存在哪些問題？
答案如下：
再來看一張RabbitMQ的學習大綱，不好展示，可以直接點擊這裏下載原圖。
更多關於Java集合、JVM、多線程併發、spring原理、微服務、Netty 與RPC 、Kafka、日記、設計模式、Java算法、數據庫、Zookeeper、分佈式緩存、數據結構面試解析等等可以去這個Github鏈接地址：https://github.com/ThinkingHan/Java-note 閱讀，Star一下吧，感謝支持~