問(wèn)題一：RabbitMQ中的 broker 是指什么？cluster 又是指什么肩榕？
答：broker是指一個(gè)或多個(gè) erlang node 的邏輯分組塘雳，且 node 上運(yùn)行著 RabbitMQ 應(yīng)用程序匾效。cluster 是在 broker 的基礎(chǔ)之上舷蟀，增加了 node 之間共享元數(shù)據(jù)的約束。
?
問(wèn)題二：什么是元數(shù)據(jù)？元數(shù)據(jù)分為哪些類型野宜？包括哪些內(nèi)容扫步？與cluster相關(guān)的元數(shù)據(jù)有哪些？元數(shù)據(jù)是如何保存的匈子？元數(shù)據(jù)在 cluster 中是如何分布的河胎？
答：在非cluster模式下，元數(shù)據(jù)主要分為 Queue 元數(shù)據(jù)（queue 名字和屬性等）旬牲、Exchange 元數(shù)據(jù)（exchange 名字仿粹、類型和屬性等）、Binding 元數(shù)據(jù)（存放路由關(guān)系的查找表）原茅、Vhost 元數(shù)據(jù)（vhost 范圍內(nèi)針對(duì)前三者的名字空間約束和安全屬性設(shè)置）。在cluster 模式下堕仔，還包括 cluster 中 node 位置信息和 node 關(guān)系信息擂橘。元數(shù)據(jù)按照 erlangnode 的類型確定是僅保存于 RAM 中，還是同時(shí)保存在 RAM 和 disk 上摩骨。元數(shù)據(jù)在cluster 中是全 node 分布的通贞。
?
問(wèn)題三：RAM node和 disk node 的區(qū)別？
答：RAM node僅將 fabric（即 queue恼五、exchange 和 binding 等 RabbitMQ 基礎(chǔ)構(gòu)件）相關(guān)元數(shù)據(jù)保存到內(nèi)存中昌罩，但 disk node 會(huì)在內(nèi)存和磁盤中均進(jìn)行存儲(chǔ)。RAM node 上唯一會(huì)存儲(chǔ)到磁盤上的元數(shù)據(jù)是 cluster 中使用的 disk node 的地址灾馒。要求在 RabbitMQ cluster中至少存在一個(gè) disk node 茎用。
?
問(wèn)題四：RabbitMQ上的一個(gè) queue 中存放的 message 是否有數(shù)量限制？
答：可以認(rèn)為是無(wú)限制睬罗，因?yàn)橄拗迫Q于機(jī)器的內(nèi)存轨功，但是消息過(guò)多會(huì)導(dǎo)致處理效率的下降。
?
問(wèn)題五：RabbitMQ概念里的 channel容达、exchange 和 queue 這些東東是邏輯概念古涧，還是對(duì)應(yīng)著進(jìn)程實(shí)體？這些東東分別起什么作用花盐？
答：queue具有自己的 erlang 進(jìn)程羡滑；exchange 內(nèi)部實(shí)現(xiàn)為保存 binding 關(guān)系的查找表；channel 是實(shí)際進(jìn)行路由工作的實(shí)體算芯，即負(fù)責(zé)按照 routing_key 將 message 投遞給queue 柒昏。由 AMQP 協(xié)議描述可知，channel 是真實(shí) TCP 連接之上的虛擬連接也祠，所有AMQP 命令都是通過(guò) channel 發(fā)送的昙楚，且每一個(gè) channel 有唯一的 ID。一個(gè) channel 只能被單獨(dú)一個(gè)操作系統(tǒng)線程使用诈嘿，故投遞到特定 channel 上的 message 是有順序的堪旧。但一個(gè)操作系統(tǒng)線程上允許使用多個(gè) channel 削葱。channel 號(hào)為 0 的 channel 用于處理所有對(duì)于當(dāng)前 connection 全局有效的幀，而 1-65535 號(hào) channel 用于處理和特定 channel 相關(guān)的幀淳梦。AMQP 協(xié)議給出的 channel 復(fù)用模型如下其中每一個(gè) channel 運(yùn)行在一個(gè)獨(dú)立的線程上析砸，多線程共享同一個(gè) socket。
?
問(wèn)題六：vhost是什么爆袍？起什么作用首繁？
答：vhost可以理解為虛擬 broker ，即 mini-RabbitMQ server陨囊。其內(nèi)部均含有獨(dú)立的queue弦疮、exchange 和 binding 等，但最最重要的是蜘醋，其擁有獨(dú)立的權(quán)限系統(tǒng)胁塞，可以做到vhost 范圍的用戶控制。當(dāng)然压语，從 RabbitMQ 的全局角度啸罢，vhost 可以作為不同權(quán)限隔離的手段（一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）√ナ常【cluster 相關(guān)】
?
?
問(wèn)題七：在單node系統(tǒng)和多 node 構(gòu)成的 cluster 系統(tǒng)中聲明 queue扰才、exchange ，以及進(jìn)行 binding 會(huì)有什么不同厕怜？答：當(dāng)你在單 node 上聲明 queue 時(shí)衩匣，只要該 node 上相關(guān)元數(shù)據(jù)進(jìn)行了變更，你就會(huì)得到 Queue.Declare-ok 回應(yīng)酣倾；而在 cluster 上聲明 queue 舵揭，則要求 cluster 上的全部node 都要進(jìn)行元數(shù)據(jù)成功更新，才會(huì)得到 Queue.Declare-ok 回應(yīng)躁锡。另外午绳，若 node 類型為 RAM node 則變更的數(shù)據(jù)僅保存在內(nèi)存中，若類型為 disk node 則還要變更保存在磁盤上的數(shù)據(jù)映之。
?
?
?
?
問(wèn)題八：客戶端連接到cluster中的任意 node 上是否都能正常工作拦焚？
答：是的「苁洌客戶端感覺不到有何不同赎败。
?
問(wèn)題九：若cluster中擁有某個(gè) queue 的 owner node 失效了，且該 queue 被聲明具有durable 屬性蠢甲，是否能夠成功從其他 node 上重新聲明該 queue 僵刮？
答：不能，在這種情況下，將得到404 NOT_FOUND錯(cuò)誤搞糕。只能等 queue 所屬的 node恢復(fù)后才能使用該 queue 勇吊。但若該 queue 本身不具有 durable 屬性，則可在其他 node上重新聲明窍仰。
?
問(wèn)題十：cluster中 node 的失效會(huì)對(duì) consumer 產(chǎn)生什么影響汉规？若是在 cluster 中創(chuàng)建了mirrored queue ，這時(shí) node 失效會(huì)對(duì) consumer 產(chǎn)生什么影響驹吮？
答：若是consumer所連接的那個(gè) node 失效（無(wú)論該 node 是否為 consumer 所訂閱queue 的 owner node）针史，則 consumer 會(huì)在發(fā)現(xiàn) TCP 連接斷開時(shí)，按標(biāo)準(zhǔn)行為執(zhí)行重連邏輯碟狞，并根據(jù)“Assume Nothing”原則重建相應(yīng)的 fabric 即可啄枕。若是失效的 node 為consumer 訂閱 queue 的 owner node，則 consumer 只能通過(guò) Consumer CancellationNotification 機(jī)制來(lái)檢測(cè)與該 queue 訂閱關(guān)系的終止族沃，否則會(huì)出現(xiàn)傻等卻沒(méi)有任何消息來(lái)到的問(wèn)題射亏。
?
問(wèn)題十一：能夠在地理上分開的不同數(shù)據(jù)中心使用RabbitMQ cluster么？
答：不能竭业。第一，你無(wú)法控制所創(chuàng)建的queue實(shí)際分布在 cluster 里的哪個(gè) node 上（一般使用 HAProxy + cluster 模型時(shí)都是這樣）及舍，這可能會(huì)導(dǎo)致各種跨地域訪問(wèn)時(shí)的常見問(wèn)題未辆；第二西轩，Erlang 的 OTP 通信框架對(duì)延遲的容忍度有限师崎，這可能會(huì)觸發(fā)各種超時(shí)，導(dǎo)致業(yè)務(wù)疲于處理通孽；第三攘残，在廣域網(wǎng)上的連接失效問(wèn)題將導(dǎo)致經(jīng)典的“腦裂”問(wèn)題拙友，而RabbitMQ 目前無(wú)法處理（該問(wèn)題主要是說(shuō) Mnesia）〖吖【綜合問(wèn)題】
?
問(wèn)題十二：為什么heavy RPC的使用場(chǎng)景下不建議采用 disk node 遗契？
答：heavy RPC是指在業(yè)務(wù)邏輯中高頻調(diào)用 RabbitMQ 提供的 RPC 機(jī)制，導(dǎo)致不斷創(chuàng)建病曾、銷毀 reply queue 牍蜂，進(jìn)而造成 disk node 的性能問(wèn)題（因?yàn)闀?huì)針對(duì)元數(shù)據(jù)不斷寫盤）。所以在使用 RPC 機(jī)制時(shí)需要考慮自身的業(yè)務(wù)場(chǎng)景泰涂。問(wèn)題十三：向不存在的 exchange 發(fā) publish 消息會(huì)發(fā)生什么鲫竞？向不存在的 queue 執(zhí)行consume 動(dòng)作會(huì)發(fā)生什么？答：都會(huì)收到 Channel.Close 信令告之不存在（內(nèi)含原因 404 NOT_FOUND）逼蒙。
?
問(wèn)題十四：routing_key和 binding_key 的最大長(zhǎng)度是多少从绘？
答：255字節(jié)。問(wèn)題十五：RabbitMQ 允許發(fā)送的 message 最大可達(dá)多大？答：根據(jù) AMQP 協(xié)議規(guī)定僵井，消息體的大小由 64-bit 的值來(lái)指定陕截，所以你就可以知道到底能發(fā)多大的數(shù)據(jù)了。
問(wèn)題十六：什么情況下producer不主動(dòng)創(chuàng)建 queue 是安全的驹沿？
答：1.message是允許丟失的艘策；2.實(shí)現(xiàn)了針對(duì)未處理消息的 republish 功能（例如采用Publisher Confirm 機(jī)制）。
?
問(wèn)題十七：“dead letter”queue 的用途渊季？
答：當(dāng)消息被RabbitMQ server投遞到 consumer 后朋蔫，但 consumer 卻通過(guò) Basic.Reject進(jìn)行了拒絕時(shí)（同時(shí)設(shè)置 requeue=false），那么該消息會(huì)被放入“dead letter”queue 中却汉。該 queue 可用于排查 message 被 reject 或 undeliver 的原因驯妄。
?
問(wèn)題十八：為什么說(shuō)保證message被可靠持久化的條件是 queue 和 exchange 具有durable 屬性，同時(shí) message 具有 persistent 屬性才行合砂？
答：binding關(guān)系可以表示為 exchange – binding – queue 青扔。從文檔中我們知道，若要求投遞的 message 能夠不丟失翩伪，要求 message 本身設(shè)置 persistent 屬性微猖，要求 exchange和 queue 都設(shè)置 durable 屬性。其實(shí)這問(wèn)題可以這么想缘屹，若 exchange 或 queue 未設(shè)置durable 屬性凛剥，則在其 crash 之后就會(huì)無(wú)法恢復(fù)，那么即使 message 設(shè)置了 persistent 屬性轻姿，仍然存在 message 雖然能恢復(fù)但卻無(wú)處容身的問(wèn)題犁珠；同理，若 message 本身未設(shè)置persistent 屬性互亮，則 message 的持久化更無(wú)從談起犁享。
?
問(wèn)題十九：什么情況下會(huì)出現(xiàn)blackholed問(wèn)題？
答：blackholed問(wèn)題是指豹休，向 exchange 投遞了 message 炊昆，而由于各種原因?qū)е略搈essage 丟失，但發(fā)送者卻不知道慕爬∫っ校可導(dǎo)致 blackholed 的情況：1.向未綁定 queue 的exchange 發(fā)送 message；2.exchange 以 binding_key key_A 綁定了 queue queue_A医窿，但向該 exchange 發(fā)送 message 使用的 routing_key 卻是 key_B磅甩。
?
問(wèn)題二十：如何防止出現(xiàn)blackholed問(wèn)題？答：沒(méi)有特別好的辦法姥卢，只能在具體實(shí)踐中通過(guò)各種方式保證相關(guān) fabric 的存在卷要。另外渣聚，如果在執(zhí)行 Basic.Publish 時(shí)設(shè)置 mandatory=true ，則在遇到可能出現(xiàn) blackholed 情況時(shí)僧叉，服務(wù)器會(huì)通過(guò)返回 Basic.Return 告之當(dāng)前 message 無(wú)法被正確投遞（內(nèi)含原因 312NO_ROUTE）奕枝。
?
問(wèn)題二十一：Consumer Cancellation Notification機(jī)制用于什么場(chǎng)景？答：用于保證當(dāng)鏡像 queue 中 master 掛掉時(shí)瓶堕，連接到 slave 上的 consumer 可以收到自身 consume 被取消的通知隘道，進(jìn)而可以重新執(zhí)行 consume 動(dòng)作從新選出的 master 出獲得消息。若不采用該機(jī)制郎笆，連接到 slave 上的 consumer 將不會(huì)感知 master 掛掉這個(gè)事情谭梗，導(dǎo)致后續(xù)無(wú)法再收到新 master 廣播出來(lái)的 message 。另外宛蚓，因?yàn)樵阽R像 queue 模式下激捏，存在將 message 進(jìn)行 requeue 的可能，所以實(shí)現(xiàn) consumer 的邏輯時(shí)需要能夠正確處理出現(xiàn)重復(fù) message 的情況凄吏。
?
問(wèn)題二十二：Basic.Reject的用法是什么远舅？
答：該信令可用于consumer對(duì)收到的 message 進(jìn)行 reject 。
若在該信令中設(shè)置requeue=true痕钢，則當(dāng) RabbitMQ server 收到該拒絕信令后图柏，會(huì)將該 message 重新發(fā)送到下一個(gè)處于 consume 狀態(tài)的 consumer 處（理論上仍可能將該消息發(fā)送給當(dāng)前consumer）。
若設(shè)置requeue=false任连，則 RabbitMQ server 在收到拒絕信令后爆办，將直接將該message 從 queue 中移除。另外一種移除 queue 中 message 的小技巧是课梳，consumer 回復(fù) Basic.Ack 但不對(duì)獲取到的message 做任何處理。而 Basic.Nack 是對(duì) Basic.Reject 的擴(kuò)展余佃，以支持一次拒絕多條 message 的能力暮刃。
?
問(wèn)題二十三：為什么不應(yīng)該對(duì)所有的message都使用持久化機(jī)制？
答：首先爆土，必然導(dǎo)致性能的下降椭懊，因?yàn)閷懘疟P比寫RAM慢的多，message 的吞吐量可能有 10 倍的差距步势。其次氧猬，message 的持久化機(jī)制用在 RabbitMQ 的內(nèi)置 cluster 方案時(shí)會(huì)出現(xiàn)“坑爹”問(wèn)題。矛盾點(diǎn)在于坏瘩，若 message 設(shè)置了 persistent 屬性盅抚，但 queue 未設(shè)置durable 屬性，那么當(dāng)該 queue 的 owner node 出現(xiàn)異常后倔矾，在未重建該 queue 前妄均，發(fā)往該 queue 的 message 將被 blackholed 柱锹；若 message 設(shè)置了 persistent 屬性，同時(shí)queue 也設(shè)置了 durable 屬性丰包，那么當(dāng) queue 的 owner node 異常且無(wú)法重啟的情況下禁熏，則該 queue 無(wú)法在其他 node 上重建，只能等待其 owner node 重啟后邑彪，才能恢復(fù)該 queue 的使用瞧毙，而在這段時(shí)間內(nèi)發(fā)送給該 queue 的 message 將被 blackholed 。所以寄症，是否要對(duì) message 進(jìn)行持久化宙彪，需要綜合考慮性能需要，以及可能遇到的問(wèn)題瘸爽。若想達(dá)到 100,000 條/秒以上的消息吞吐量（單 RabbitMQ 服務(wù)器）您访，則要么使用其他的方式來(lái)確保 message 的可靠 delivery ，要么使用非臣艟觯快速的存儲(chǔ)系統(tǒng)以支持全持久化（例如使用 SSD）灵汪。另外一種處理原則是：僅對(duì)關(guān)鍵消息作持久化處理（根據(jù)業(yè)務(wù)重要程度），且應(yīng)該保證關(guān)鍵消息的量不會(huì)導(dǎo)致性能瓶頸柑潦。
重點(diǎn)：RabbitMQ核心概念
·生產(chǎn)者（Producer）：發(fā)送消息的應(yīng)用享言。
·消費(fèi)者（Consumer）：接收消息的應(yīng)用。
·隊(duì)列（Queue）：存儲(chǔ)消息的緩存渗鬼。
·消息（Message）：又生產(chǎn)者通過(guò)RabbitMQ發(fā)送給消費(fèi)者的信息览露。
·連接（Connection）：連接RabbitMQ和應(yīng)用服務(wù)器的TCP連接。
·通道（Channel）：連接里的一個(gè)虛擬通道譬胎。當(dāng)你通過(guò)消息隊(duì)列發(fā)送或者接收消息時(shí)差牛，這個(gè)操作都是通過(guò)通道進(jìn)行的。
·交換機(jī)（Exchange）：從生產(chǎn)者那里接收消息堰乔，并根據(jù)交換類型分發(fā)到對(duì)應(yīng)的消息列隊(duì)里偏化。要實(shí)現(xiàn)消息的接收，一個(gè)隊(duì)列必須綁定一個(gè)交換機(jī)镐侯。
·綁定（Binding）：綁定是隊(duì)列和交換機(jī)的一個(gè)鏈接侦讨。
·路由鍵（Routing Key）：路由鍵是供交換機(jī)查看并根據(jù)鍵的值來(lái)決定如何分發(fā)消息到列隊(duì)的一個(gè)鍵。路由鍵可以說(shuō)是消息的目的地址苟翻。
·?AMQP：AMQP（高級(jí)消息隊(duì)列協(xié)議Advanced Message Queuing Protocol）是RabbitMQ使用的消息協(xié)議韵卤。
·用戶（Users）：在RabbitMQ里，是可以通過(guò)指定的用戶名和密碼來(lái)進(jìn)行連接的崇猫。每個(gè)用戶可以分配不同的權(quán)限沈条，例如讀權(quán)限，寫權(quán)限以及在實(shí)例里進(jìn)行配置的權(quán)限诅炉。
?
ConnectionFactory（連接管理器）：應(yīng)用程序與Rabbit之間建立連接的管理器拍鲤，程序代碼中使用贴谎；
Channel（信道）：消息推送使用的通道；
Exchange（交換器）：用于接受季稳、分配消息擅这；
Queue（隊(duì)列）：用于存儲(chǔ)生產(chǎn)者的消息；
RoutingKey（路由鍵）：用于把生成者的數(shù)據(jù)分配到交換器上景鼠；
BindingKey（綁定鍵）：用于把交換器的消息綁定到隊(duì)列上仲翎；
?
?
