- AMQP簡介
AMQP（Advanced Message Queuing Protocol，高級消息隊列協(xié)議）
是一個進程間傳遞異步消息的網(wǎng)絡協(xié)議,主要實現(xiàn)為RabbitMQ。
AMQP模型
- 生產(chǎn)者:消息的創(chuàng)建者，發(fā)送消息到rabbitmq；
- 消費者：連接到rabbitmq，訂閱到隊列上進行消費消息，持續(xù)訂閱(basicConsumer)和單條訂閱(basicGet).
- 消息：包含有效載荷和標簽，有效載荷指要傳輸?shù)臄?shù)據(jù)，，標簽描述了有效載荷，
并且rabbitmq用它來決定誰獲得消息，消費者只能拿到有效載荷，并不知道生產(chǎn)者是誰信道：生產(chǎn)者與消費者均通過信道與MQ通信，一個TCP連接有成百上千個信道來達到多線程
處理，交換器、隊列、綁定、路由鍵,隊列通過路由鍵（routing key，某種確定的規(guī)則）綁定到交換器，
生產(chǎn)者將消息發(fā)布到交換器，交換器根據(jù)綁定的路由鍵將消息路由到特定隊列，然后由訂閱這個隊列的消費者進行接收
- RabbitMQ 中的 Broker 是指什么？Cluster 又是指什么？
- broker 是指一個或多個 erlang node 的邏輯分組，且 node 上運行著 RabbitMQ 應用程序
- cluster 是在 broker 的基礎之上，增加了 node 之間共享元數(shù)據(jù)的約束
- 什么是元數(shù)據(jù)？元數(shù)據(jù)分為哪些類型？包括哪些內(nèi)容
在非 Cluster 模式下，元數(shù)據(jù)主要分為：
- Queue 元數(shù)據(jù)（queue 的名字和屬性等），具有自己的 erlang 進程
- Exchange 元數(shù)據(jù)（exchange 名字、類型和屬性等），內(nèi)部實現(xiàn)為保存 binding 關系的查找表
- Binding 元數(shù)據(jù)（存放路由關系的查找表）
- Vhost 元數(shù)據(jù)（vhost 范圍內(nèi)針對前三者的名字空間約束和安全屬性設置），擁有獨立的權限，
可用來做范圍控制。
- 如何確保消息正確地發(fā)送至 RabbitMQ？
RabbitMQ 使用發(fā)送方確認模式，確保消息正確地發(fā)送到 RabbitMQ
當采用channel.confirmSelect();開啟確認者發(fā)送模式后，可采用以下方法確認消息，
- channel.addConfirmListener()添加異步監(jiān)聽發(fā)送方確認模式
- channel.waitForConfirms()普通發(fā)送方確認模式；消息到達交換器，就會返回true
- channel.waitForConfirmsOrDie()批量確認模式；只要有一個未確認就會IOException
- 常用的交換器有哪些
- direct是精準匹配，對于匹配符合的消費者都推送消息
- fanout是廣播式發(fā)送，所有消費者均能收到消息
- topic，通過"."分割路由鍵,"*"進行1個匹配,"#"N個匹配，
- headers(通direct差不多)
- metadata的存儲方式 RAM node和disk node
- RAM node,將queue、exchange 和 binding等 RabbitMQ基礎構(gòu)件存儲在內(nèi)存中，
- disk node,不但保存到內(nèi)存中，還會保存到磁盤上，一個cluster至少有一個disk node用來持久化
- 在單 node 系統(tǒng)和多 node 構(gòu)成的 cluster 系統(tǒng)中聲明 queue、exchange ，以及 進行 binding 會有什么不同?
- 單 node 上聲明 queue 時，只要
該 node上相關元數(shù)據(jù)進行了變更，你就會 得到
Queue.Declare-ok 回應- cluster 上聲明 queue ，則要求 cluster 上的
全部 node都要進行元數(shù)據(jù)成功更新，
才會得到 Queue.Declare-ok 回應。另外，若 node 類型 為 RAM node 則變更的數(shù)據(jù)僅
保存在內(nèi)存中，若類型為 disk node 則還要變更保存在磁盤 上的數(shù)據(jù)。
- cluster 中擁有某個 queue 的 owner node 失效了,其他node能否重新聲明
- durable持久化的queue只能重新恢復才能使用該queue
- 非durable的可以重新聲明
- 能夠在地理上分開的不同數(shù)據(jù)中心使用 RabbitMQ cluster 么
- 無法控制所創(chuàng)建的 queue 實際分布在 cluster 里的哪個 node 上(一 般使用
HAProxy + cluster 模型時都是這樣)，這可能會導致各種跨地域訪問時的常見問題- Erlang 的 OTP 通信框架對延遲的容忍度有限，這可能會觸發(fā)各種超時，導致 業(yè)務疲于處理
- 在廣域網(wǎng)上的連接失效問題將導致經(jīng)典的“腦裂”問題，而 RabbitMQ 目前無法處理
- routing_key 和 binding_key 的最大長度是多少
255字節(jié)
- 向不存在的 exchange 發(fā) publish 消息會發(fā)生什么
都會收到 Channel.Close 信令告之不存在(內(nèi)含原因 404 NOT_FOUND)
- 什么情況下 producer 不主動創(chuàng)建 queue 是安全的?
- message 是允許丟失的
- 實現(xiàn)了針對未處理消息的 republish 功能(例如采用 Publisher Confirm 機制)。
- 死信交換器DLX(
一個普通交換器,在隊列聲明參數(shù) x-dead-letter-exchange 開啟,x-dead-letter-routing-key，后
當發(fā)生以下情況，消息會進入死信隊列：
- 消息被拒絕,requeue參數(shù)為false
- 消息過期
- 隊列達到最長長度
死信和備用的區(qū)別
- 備用是路由失敗的消息，死信是路由成功拒絕或未響應的消息
- 備用是在隊列申明，死信是在交換器申明
- 什么情況下會出現(xiàn) blackholed 黑洞問題?
blackholed 問題是指，向 exchange 投遞了 message ，而由于各種原因?qū)е略?br> message 丟失，但發(fā)送者卻不知道。可以通過 mandatory=true，來接收路由失敗的消息
可導致 blackholed 的情況:
- 向未綁定 queue 的 exchange 發(fā)送 message
- exchange 以 binding_key key_A 綁定了一個 queue queue_A，但向 該
exchange 發(fā)送 message 使用的 routing_key 卻是 key_B。
- 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 的情況
- 消息的拒絕
消息消費異常,拒絕回mq,進行重新發(fā)送給其他消費者消費
- reject 拒絕單條消息channel.basicReject(envelope.getDeliveryTag(),false);
- Nack 多條拒絕
- 為什么不應該對所有的 message 都使用持久化機制?
僅對關鍵消息作持久化處理(根據(jù)業(yè)務重要程度)，且應該保證關鍵消息的量不會導致性能瓶頸
- 性能影響
- queue持久化會導致無法重新聲明，而丟失消息
