前言

寫在正文之前，最近很多小伙伴都在考慮要不要加入本次金三銀四，那么他們害怕的點在哪里呢？無非就是下面這兩點！

• 疫情當前，很多公司、企業都在不斷裁員，害怕跳槽只跳了一半，自己跳了出去卻沒有公司要自己，
• 覺得自己作業經驗不夠，想在小公司再干一年，

以上這兩點總結下來其實就是一句話！

對于自己的實力沒有信心，自己所掌握的知識點還不足以支撐自己去跳槽，找到高薪崗位！

我其實一直有一句座右銘：新年過完了，其實馬上就是下一個新年了，每次都想著等一等在去努力、等一等再去沖刺，那么永遠都會慢別人一步！

所以趕緊加我的助理小姐姐VX：C18173184271 領取 Java高階學習資源 和 互聯網企業面經！

正文

問題一：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 分布的，

問題三：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 相關的幀，

其中每一個 channel 運行在一個獨立的執行緒上，多執行緒共享同一個 socket，

問題四：vhost 是什么？起什么作用？

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

問題五：若 cluster 中擁有某個 queue 的 owner node 失效了，且該 queue 被宣告具有 durable 屬性，是否能夠成功從其他 node 上重新宣告該 queue ？

答：不能，在這種情況下，將得到 404 NOT_FOUND 錯誤，只能等 queue 所屬的 node 恢復后才能使用該 queue ，但若該 queue 本身不具有 durable 屬性，則可在其他 node 上重新宣告，

問題六：能夠在地理上分開的不同資料中心使用 RabbitMQ cluster 么？

答：不能，第一，你無法控制所創建的 queue 實際分布在 cluster 里的哪個 node 上（一般使用 HAProxy + cluster 模型時都是這樣），這可能會導致各種跨地域訪問時的常見問題；第二，Erlang 的 OTP 通信框架對延遲的容忍度有限，這可能會觸發各種超時，導致業務疲于處理；第三，在廣域網上的連接失效問題將導致經典的“腦裂”問題，而 RabbitMQ 目前無法處理（該問題主要是說 Mnesia），

問題七：為什么 heavy RPC 的使用場景下不建議采用 disk node ？

答：heavy RPC 是指在業務邏輯中高頻呼叫 RabbitMQ 提供的 RPC 機制，導致不斷創建、銷毀 reply queue ，進而造成 disk node 的性能問題（因為會針對元資料不斷寫盤），所以在使用 RPC 機制時需要考慮自身的業務場景，

問題八：Basic.Reject 的用法是什么？

答：該信令可用于 consumer 對收到的 message 進行 reject ，若在該信令中設定 requeue=true，則當 RabbitMQ server 收到該拒絕信令后，會將該 message 重新發送到下一個處于 consume 狀態的 consumer 處（理論上仍可能將該訊息發送給當前 consumer），若設定 requeue=false ，則 RabbitMQ server 在收到拒絕信令后，將直接將該 message 從 queue 中移除，

問題九：為什么不應該對所有的 message 都使用持久化機制？

答：首先，必然導致性能的下降，因為寫磁盤比寫 RAM 慢的多，message 的吞吐量可能有 10 倍的差距，其次，message 的持久化機制用在 RabbitMQ 的內置 cluster 方案時會出現“坑爹”問題，矛盾點在于，若 message 設定了 persistent 屬性，但 queue 未設定 durable 屬性，那么當該 queue 的 owner node 出現例外后，在未重建該 queue 前，發往該 queue 的 message將被 blackholed ；若 message 設定了 persistent 屬性，同時 queue 也設定了 durable 屬性，那么當 queue 的 owner node 例外且無法重啟的情況下，則該 queue 無法在其他 node 上重建，只能等待其 owner node 重啟后，才能恢復該 queue 的使用，而在這段時間內發送給該 queue 的 message 將被 blackholed，所以，是否要對 message 進行持久化，需要綜合考慮性能需要，以及可能遇到的問題，若想達到 100,000 條/秒以上的訊息吞吐量（單 RabbitMQ 服務器），則要么使用其他的方式來確保 message 的可靠 delivery ，要么使用非常快速的存盤系統以支持全持久化（例如使用 SSD），另外一種處理原則是：僅對關鍵訊息作持久化處理（根據業務重要程度），且應該保證關鍵訊息的量不會導致性能瓶頸，

問題十：RabbitMQ 中的 cluster、mirrored queue，以及 warrens 機制分別用于解決什么問題？存在哪些問題？

答：cluster 是為了解決當cluster中的任意 node失效后，producer 和 consumer 均可以通過其他 node 繼續作業，即提高了可用性；另外可以通過增加 node 數量增加 cluster的訊息吞吐量的目的，cluster 本身不負責 message 的可靠性問題（該問題由 producer 通過各種機制自行解決）；cluster 無法解決跨資料中心的問題（即腦裂問題），另外，在 cluster 前使用 HAProxy 可以解決 node 的選擇問題，即業務無需知道 cluster 中多個 node 的 ip 地址，可以利用 HAProxy 進行失效 node 的探測，可以作負載均衡，下圖為 HAProxy + cluster 的模型，

Mirrored queue 是為了解決使用 cluster 時所創建的 queue 的完整資訊僅存在于單一 node 上的問題，從另一個角度增加可用性，若想正確使用該功能，需要保證：

1. consumer 需要支持 Consumer Cancellation Notification 機制；
2. consumer 必須能夠正確處理重復 message ，

Warrens 是為了解決 cluster 中 message 可能被 blackholed 的問題，即不能接受 producer 不停 republish message 但 RabbitMQ server 無回應的情況，Warrens 有兩種構成方式，一種模型是兩臺獨立的 RabbitMQ server + HAProxy ，其中兩個 server 的狀態分別為 active 和 hot-standby ，該模型的特點為：兩臺 server 之間無任何資料共享和協議互動，兩臺 server 可以基于不同的 RabbitMQ 版本，

另一種模型為兩臺共享存盤的 RabbitMQ server + keepalived ，其中兩個 server 的狀態分別為 active 和 cold-standby ，該模型的特點為：兩臺 server 基于共享存盤可以做到完全恢復，要求必須基于完全相同的 RabbitMQ 版本，

Warrens 模型存在的問題：對于第一種模型，雖然理論上講不會丟失訊息，但若在該模型上使用持久化機制，就會出現這樣一種情況，即若作為 active 的 server 例外后，持久化在該 server 上的訊息將暫時無法被 consume ，因為此時該 queue 將無法在作為 hot-standby 的 server 上被重建，所以，只能等到例外的 active server 恢復后，才能從其上的 queue 中獲取相應的 message 進行處理，而對于業務來說，需要具有：a.感知 AMQP 連接斷開后重建各種 fabric 的能力；b.感知 active server 恢復的能力；c.切換回 active server 的時機控制，以及切回后，針對 message 先后順序產生的變化進行處理的能力，對于第二種模型，因為是基于共享存盤的模式，所以導致 active server 例外的條件，可能同樣會導致 cold-standby server 例外；另外，在該模型下，要求 active 和 cold-standby 的 server 必須具有相同的 node 名和 UID ，否則將產生訪問權限問題；最后，由于該模型是冷備方案，故無法保證 cold-standby server 能在你要求的時限內成功啟動，

寫在最后

不在在因為等一會，讓自己錯過一次又一次的機會，任何機遇都伴有風險，只有不斷前行才能取得成功！

趕緊加我的助理小姐姐VX：C18173184271 領取 Java高階學習資源 和 互聯網企業面經！

最后求一個一鍵三連不過分吧！