1蔗包、RabbitMQ中的broker是指什么结笨？cluster又是指什么签夭？
broker是指一個或多個erlang node的邏輯分組昌渤，且node上運行著 RabbitMQ應用程序赴穗。cluster是在broker的基礎之上，增加了 node之間 共享元數據的約束膀息。
2般眉、什么是元數據？元數據分為哪些類型潜支？包括哪些內容甸赃？與cluster相關的元數據有哪些？元數據是如何保存的冗酿？元數據在cluster中是如何分布的埠对？
在非cluster模式下，元數據主要分為Queue元數據（queue名字和屬性 等）裁替、Exchange元數據（exchange名字项玛、類型和屬性等）、Binding元數據 （存放路由關系的查找表）弱判、Vhost元數據（vhost范圍內針對前三者的名字空 間約束和安全屬性設置）襟沮。
在cluster模式下，還包括cluster中node位置信息和node關系信息。元數據按照erlang node的類型確定是僅保存于RAM中开伏，還是同時保存在RAM和disk上膀跌。元數據在cluster中是全node 分布的。
3固灵、RAM node 和 disk node 的區(qū)別捅伤？
RAM node 僅將 fabric（即 queue、exchange 和 binding等 RabbitMQ基礎構 件）相關元數據保存到內存中巫玻，但disk node會在內存和磁盤中均進行存 儲丛忆。RAM node上唯一會存儲到磁盤上的元數據是cluster中使用的disk node的地址。要求在RabbitMQ cluster中至少存在一個disk node大审。
4蘸际、RabbitMQ上的一個queue中存放的message是否有數量限制？
可以認為是無限制徒扶，因為限制取決于機器的內存粮彤，但是消息過多會導致處 理效率的下降。
5姜骡、vhost是什么导坟？起什么作用？
vhost可以理解為虛擬broker 圈澈，即mini-RabbitMQ server惫周。其內部均含有 獨立的queue、exchange和binding等康栈，但最最重要的是递递，其擁有獨立的 權限系統(tǒng)，可以做到vhost范圍的用戶控制啥么。當然登舞，從RabbitMQ的全局 角度，vhost可以作為不同權限隔離的手段（一個典型的例子就是不同的應 用可以跑在不同的vhost中）悬荣。
6菠秒、在單node系統(tǒng)和多node構成的cluster系統(tǒng)中聲明queue、exchange氯迂，以及進行binding會有什么不同践叠？
當你在單node上聲明queue時，只要該node上相關元數據進行了變 更嚼蚀，你就會得到Queue.Declare-ok回應禁灼；而在cluster上聲明queue，則要 求cluster上的全部node都要進行元數據成功更新轿曙，才會得到 Queue.Declare-ok回應匾二。另外哮独，若node類型為RAM node則變更的數據 僅保存在內存中，若類型為disk node則還要變更保存在磁盤上的數據察藐。
7、客戶端連接到cluster中的任意node上是否都能正常工作舟扎？
是的分飞。客戶端感覺不到有何不同睹限。
8譬猫、若cluster中擁有某個queue的owner node失效了，且該queue 被聲明具有durable屬性羡疗，是否能夠成功從其他node上重新聲明該 queue 染服？
不能，在這種情況下叨恨，將得到404 NOT_FOUND錯誤柳刮。只能等queue所 屬的node恢復后才能使用該queue。但若該queue本身不具有durable 屬性痒钝，則可在其他node上重新聲明秉颗。
9、cluster中node的失效會對consumer產生什么影響送矩？若是在 cluster 中創(chuàng)建了 mirrored queue蚕甥，這時 node 失效會對 consumer 產生什么影響？
若是consumer所連接的那個node失效（無論該node是否為consumer 所訂閱queue的owner node）栋荸，則consumer會在發(fā)現(xiàn)TCP連接斷開時菇怀， 按標準行為執(zhí)行重連邏輯，并根據“Assume Nothing”原則重建相應的 fabric 即可晌块。若是失效的 node 為 consumer 訂閱 queue 的 o wner node爱沟， 則 consumer 只能通過 Consumer Cancellation Notification 機制來檢測與 該queue訂閱關系的終止，否則會出現(xiàn)傻等卻沒有任何消息來到的問 題摸袁。
10钥顽、能夠在地理上分開的不同數據中心使用RabbitMQ cluster么？
不能靠汁。
第一蜂大，你無法控制所創(chuàng)建的queue實際分布在cluster里的哪個node上 （一般使用HAProxy + cluster模型時都是這樣），這可能會導致各種跨地域 訪問時的常見問題蝶怔；
第二奶浦，Erlang的OTP通信框架對延遲的容忍度有限，這可能會觸發(fā)各種 超時踢星，導致業(yè)務疲于處理澳叉；
第三，在廣域網上的連接失效問題將導致經典的“腦裂"問題，而 RabbitMQ目前無法處理（該問題主要是說Mnesia）成洗。
11五督、為什么heavy RPC的使用場景下不建議采用disk node
heavy RPC是指在業(yè)務邏輯中高頻調用RabbitMQ提供的RPC機制，導 致不斷創(chuàng)建瓶殃、銷毀reply queue充包，進而造成disk node的性能問題（因為會 針對元數據不斷寫盤）。所以在使用RPC機制時需要考慮自身的業(yè)務場景遥椿。
12基矮、向不存在的exchange發(fā)publish消息會發(fā)生什么？向不存在的 queue執(zhí)行c onsume動作會發(fā)生什么冠场？
都會收到ChanneLClose信令告之不存在（內含原因404 NOT_FOUND）家浇。
13、routing_key和binding_key的最大長度是多少碴裙？
255字節(jié)钢悲。
14、RabbitMQ允許發(fā)送的message最大可達多大青团？
根據AMQP協(xié)議規(guī)定譬巫，消息體的大小由64-bit的值來指定，所以你就可 以知道到底能發(fā)多大的數據了督笆。
15芦昔、什么情況下producer不主動創(chuàng)建queue是安全的？
message是允許丟失的娃肿；
實現(xiàn)了針對未處理消息的republish功能（例如采用Publisher Confirm機 制）咕缎。
16、"dead letter" queue 的用途料扰？
當消息被RabbitMQ server投遞到consumer后凭豪，但consumer卻通過 Basic.Reject進行了拒絕時（同時設置requeue=false），那么該消息會被放 入“dead letter"queue 中晒杈。該 queue 可用于排查 message 被 reject 或 undeliver 的原因嫂伞。
17、什么說保證message被可靠持久化的條件是queue和exchange 具有durable屬性拯钻，同時message具有persistent屬性才行帖努？
binding關系可以表示為exchange - binding - queue。從文檔中我們知 道粪般，若要求投遞的message能夠不丟失拼余，要求message本身設置 persistent屬性，要求exchange和queue都設置durable屬性亩歹。
其實這問 題可以這么想匙监，若exchange或queue未設置durable屬性凡橱，則在其 crash之后就會無法恢復，那么即使message設置了 persistent屬性亭姥，仍 然存在message雖然能恢復但卻無處容身的問題稼钩；同理，若message本身 未設置persistent屬性致份，則message的持久化更無從談起变抽。
18、什么情況下會出現(xiàn)blackholed問題氮块？
blackholed問題是指，向exchange投遞了 message诡宗，而由于各種原因導 致該message丟失滔蝉，但發(fā)送者卻不知道∷郑可導致blackholed的情況：
向未綁定 queue 的 exchange 發(fā)送 message蝠引；
exchange 以 binding_key key_A 綁定了 queue queue_A，但向該 exchange 發(fā)送 message 使用的 routing_key 去卩是 key_B蛀柴。
19螃概、如何防止出現(xiàn)blackholed問題？
沒有特別好的辦法鸽疾，只能在具體實踐中通過各種方式保證相關fabric的存 在吊洼。另外，如果在執(zhí)行Basic.Publish時設置mandatory=true制肮，則在遇到 可能出現(xiàn)blackholed情況時冒窍，服務器會通過返回Basic.Return告之當前 message無法被正確投遞（內含原因312 NO_ROUTE）豺鼻。
20综液、Consumer Cancellation Notification 機制用于什么場景？
用于保證當鏡像queue中master掛掉時儒飒，連接到slave上的consumer可 以收到自身consume被取消的通知谬莹，進而可以重新執(zhí)行consume動作從 新選出的master出獲得消息附帽。
若不采用該機制，連接到slave上的 consumer將不會感知master掛掉這個事情送悔，導致后續(xù)無法再收到新 master廣播出來的message。
另外荚藻，因為在鏡像queue模式下应狱，存在將 message進行requeue的可能，所以實現(xiàn)consumer的邏輯時需要能夠正 確處理出現(xiàn)重復message的情況除嘹。
21、Basic.Reject的用法是什么年缎？
該信令可用于consumer對收到的message進行reject单芜。若在該信令中設 置requeue=true，則當RabbitMQ server收到該拒絕信令后赁温，會將該 message重新發(fā)送到下一個處于consume狀態(tài)的consumer處（理論上仍 可能將該消息發(fā)送給當前consumer）股囊。若設置requeue=false居灯，則 RabbitMQ server在收到拒絕信令后怪嫌，將直接將該message從queue中移 除岩灭。
另外一種移除queue中message的小技巧是噪径，consumer回復Basic.Ack 但不對獲取到的message做任何處理。
而Basic.Nack是對Basic.Reject的擴展梗顺，以支持一次拒絕多條message 的能力寺谤。
22变屁、為什么不應該對所有的message都使用持久化機制摄职？
首先谷市，必然導致性能的下降击孩，因為寫磁盤比寫RAM慢的多，message的 吞吐量可能有10倍的差距。其次，message的持久化機制用在 RabbitMQ的內置cluster方案時會出現(xiàn)“坑爹”問題法绵。矛盾點在于盐茎，若 message設置了 persistent屬性探越，但 queue未設置 durable屬性，那么當 該queue的owner node出現(xiàn)異常后，在未重建該queue前东抹，發(fā)往該 queue 的 message 將被 blackholed 别渔；若 message 設置了 persistent 屬性哎媚， 同時queue也設置了 durable屬性，那么當queue的owner node異常且 無法重啟的情況下截珍，則該queue無法在其他node上重建，只能等待其 owner node重啟后事期，才能恢復該queue的使用稠鼻，而在這段時間內發(fā)送給 該queue的message將被blackholed。
所以唉匾，是否要對message進行持久化巍膘，需要綜合考慮性能需要磷支，以及可能遇到的問題。若想達到 100，000條/秒以上的消息吞吐量（單RabbitMQ服務器）咒循，則要么使用其他 的方式來確保message的可靠delivery，要么使用非常快速的存儲系統(tǒng)以 支持全持久化（例如使用SSD）。另外一種處理原則是:僅對關鍵消息作持久 化處理（根據業(yè)務重要程度），且應該保證關鍵消息的量不會導致性能瓶 頸。
23睹晒、RabbitMQ 中的 cluster锉试、mirrored queue拖云，以及 warrens 機制分 別用于解決什么問題？存在哪些問題应又？
cluster是為了解決當cluster中的任意node失效后宙项，producer和 consumer均可以通過其他node繼續(xù)工作，即提高了可用性株扛；另外可以通 過增加node數量增加cluster的消息吞吐量的目的尤筐。
cluster本身不負責 message的可靠性問題（該問題由producer通過各種機制自行解 決）；cluster無法解決跨數據中心的問題（即腦裂問題）洞就。
另外叔磷，在cluster前使用HAProxy可以解決node的選擇問題，即業(yè)務無 需知道cluster中多個node的ip地址奖磁。可以利用HAProxy進行失效node 的探測繁疤，可以作負載均衡咖为。
Mirrored queue是為了解決使用cluster時所創(chuàng)建的queue的完整信息僅 存在于單一node上的問題，從另一個角度增加可用性稠腊。若想正確使用該 功能躁染，需要保證：
consumer 需要支持 Consumer Cancellation Notification 機制；
consumer必須能夠正確處理重復message架忌。
Warrens是為了解決cluster中message可能被blackholed的問題吞彤，即不 能接受 producer 不停 republish message 但 RabbitMQ server 無回應的情況。Warrens有兩種構成方式：
一種模型是兩臺獨立的RabbitMQ server + HAProxy，其中兩個server的 狀態(tài)分別為active和hot-standby饰恕。該模型的特點為:兩臺server之間無任 何數據共享和協(xié)議交互挠羔，兩臺server可以基于不同的RabbitMQ版本违霞。
另一種模型為兩臺共享存儲的RabbitMQ server + keepalived蚌讼，其中兩個 server 的狀態(tài)分別為 active 和 cold-standby轨帜。
該模型的特點為:兩臺server基于共享存儲可以做到完全恢復喻频，要求必須 基于完全相同的RabbitMQ版本批旺。
Warrens模型存在的問題：
對于第一種模型祭往，雖然理論上講不會丟失消息爹凹，但若在該模型上使用持久 化機制衫樊，就會出現(xiàn)這樣一種情況了罪，即若作為active的server異常后锭环，持久 化在該server上的消息將暫時無法被consume，因為此時該queue將無 法在作為hot- standby的server上被重建泊藕，所以辅辩，只能等到異常的active server恢復后，才能從其上的queue中獲取相應的message進行處理吱七。 而對于業(yè)務來說汽久，需要具有:a .感知AMQP連接斷開后重建各種fabric的能 力；b.感知active server恢復的能力踊餐；c.切換回active server的時機控制景醇，以及切回后，針對message先后順序產生的變化進行處理的能力吝岭。
對于第二種模型三痰，因為是基于共享存儲的模式，所以導致active server異 常的條件窜管，可能同樣會導致cold-standby server異常散劫；另外，在該模型下幕帆， 要求active和cold-standby的server必須具有相同的node名和UID获搏，否 則將產生訪問權限問題；最后失乾，由于該模型是冷備方案常熙，故無法保證cold standby server能在你要求的時限內成功啟動。
