AMQP 0-9-1 模型解釋
AMQP 0-9-1 是什么
AMQP 0-9-1（高級(jí)消息隊(duì)列協(xié)議）是一種消息傳遞協(xié)議辉懒，可使符合要求的客戶端應(yīng)用程序與符合要求的消息傳遞中間件代理進(jìn)行通信拯啦。
代理及其角色
消息傳遞代理從發(fā)布者（發(fā)布它們的應(yīng)用程序归敬，也稱為生產(chǎn)者）接收消息蒋失，并將它們路由到消費(fèi)者（處理它們的應(yīng)用程序）
由于它是網(wǎng)絡(luò)協(xié)議月匣，因此發(fā)布者湖饱，使用者和代理都可以駐留在不同的計(jì)算機(jī)上遭殉。
AMQP 0-9-1 模型簡(jiǎn)介
AMQP 0-9-1模型具有以下世界觀：消息發(fā)布到exchange，通常與郵局或郵箱進(jìn)行比較崔泵。
然后秒赤，Exchange使用稱為綁定的規(guī)則將消息副本分發(fā)到隊(duì)列。
然后憎瘸，代理將消息傳遞給訂閱隊(duì)列的消費(fèi)者入篮，或者消費(fèi)者根據(jù)需要從隊(duì)列中獲取/拉取消息。
發(fā)布消息時(shí)幌甘，發(fā)布者可以指定各種消息屬性（消息元數(shù)據(jù)）潮售。
某些元數(shù)據(jù)可能由代理使用痊项，但是，其余部分對(duì)代理完全不透明酥诽，僅供接收消息的應(yīng)用程序使用鞍泉。
網(wǎng)絡(luò)不可靠，應(yīng)用程序可能無法處理消息肮帐，因此AMQP 0-9-1模型具有消息確認(rèn)的概念：當(dāng)消息傳遞給消費(fèi)者時(shí)咖驮，消費(fèi)者會(huì)自動(dòng)或在應(yīng)用程序開發(fā)人員選擇來這樣做時(shí)立即通知代理。當(dāng)消息確認(rèn)正在使用時(shí)训枢，代理只有在收到該消息（或消息組）的通知時(shí)才會(huì)從隊(duì)列中完全刪除消息托修。
在某些情況下，例如恒界，當(dāng)無法路由消息時(shí)诀黍，可以將消息返回給發(fā)布者，丟棄仗处，或者如果代理實(shí)現(xiàn)擴(kuò)展眯勾，則將消息放入所謂的“死信隊(duì)列”中。
發(fā)布者通過使用某些參數(shù)發(fā)布消息來選擇如何處理這種情況婆誓。
隊(duì)列吃环，exchange和綁定統(tǒng)稱為AMQP實(shí)體。
AMQP是一種可編程協(xié)議
AMQP 0-9-1是一種可編程協(xié)議洋幻，因?yàn)锳MQP 0-9-1實(shí)體和路由方案主要由應(yīng)用程序本身定義郁轻，而不是代理管理員。因此文留，規(guī)定了聲明隊(duì)列和exchange好唯，定義它們之間的綁定，訂閱隊(duì)列等的協(xié)議操作燥翅。
這為應(yīng)用程序開發(fā)人員提供了很大的自由骑篙，但也要求他們了解潛在的定義沖突。實(shí)際上森书，定義沖突很少見靶端，通常表明配置錯(cuò)誤。
應(yīng)用程序聲明它們需要的AMQP 0-9-1實(shí)體凛膏，定義必要的路由方案杨名，并且可以選擇在不再使用AMQP 0-9-1實(shí)體時(shí)刪除它們。
exchange和exchange類型
exchange是發(fā)送消息的AMQP 0-9-1實(shí)體猖毫。
exchange接收消息并將其路由到零個(gè)或多個(gè)隊(duì)列台谍。
使用的路由算法取決于exchange類型和稱為綁定的規(guī)則。
AMQP 0-9-1代理提供四種exchange類型：
Direct exchange (Empty string) and amq.direct
Fanout exchange amq.fanout
Topic exchange amq.topic
Headers exchange amq.match (and amq.headers in RabbitMQ)
除了exchange類型吁断，exchange聲明了許多屬性趁蕊，其中最重要的是：
名字
持久性 (exchanges在代理重啟后仍存在)
自動(dòng)刪除 (exchange 在最后一個(gè)隊(duì)列和他解綁后刪除)
參數(shù) (可選,用于插件和特定于代理的特性)
exchange可以是持久的或短暫的镊折。
代理重啟后持久化exchange存活，而暫時(shí)exchange則不是（當(dāng)代理重新上線時(shí)介衔，他們必須重新聲明）。
并非所有場(chǎng)景和用例都要求exchange持久骂因。
默認(rèn)exchange
默認(rèn)exchange是代理預(yù)先聲明的沒有名稱（空字符串）的直接exchange炎咖。
它有一個(gè)特殊的屬性，使它對(duì)簡(jiǎn)單的應(yīng)用程序非常有用：創(chuàng)建的每個(gè)隊(duì)列都使用與隊(duì)列名稱相同的路由鍵自動(dòng)綁定到它寒波。
例如乘盼，當(dāng)你聲明名為“search-indexing-online”的隊(duì)列時(shí)，AMQP 0-9-1代理將使用“search-indexing-online”作為路由密鑰將其綁定到默認(rèn)exchange（在此上下文有時(shí)也稱為綁定密鑰）俄烁。
因此绸栅，使用路由密鑰“search-indexing-online”發(fā)布到默認(rèn)交換的消息將被路由到隊(duì)列“search-indexing-online”。
換句話說页屠，默認(rèn)exchange使得看起來可以將消息直接傳遞到隊(duì)列粹胯，即使從技術(shù)上講這不是正在發(fā)生的事情。
直接exchange
直接exchange基于消息路由密鑰將消息傳遞到隊(duì)列辰企。
直接exchange對(duì)于消息的單播路由是理想的（盡管它們也可以用于多播路由）风纠。
下面是它的工作原理:
隊(duì)列用路由密鑰K綁定到exchange
當(dāng)具有路由密鑰R的新消息到達(dá)直接exchange時(shí)，如果K = R牢贸，則exchange將其路由到隊(duì)列
直接exchange通常用于以循環(huán)方式在多個(gè)工作者（同一應(yīng)用程序的實(shí)例）之間分配任務(wù)竹观。
這樣做時(shí)，重要的是要理解潜索，在AMQP 0-9-1中臭增，消息在消費(fèi)者之間而不是在隊(duì)列之間進(jìn)行負(fù)載平衡。
直接exchange可以用圖形表示如下：
扇出exchange
扇出exchange將消息路由到綁定到它的所有隊(duì)列竹习，并忽略路由密鑰誊抛。
如果N個(gè)隊(duì)列綁定到扇出exchange，則當(dāng)向該exchange發(fā)布新消息時(shí)整陌，該消息的副本將被傳遞到所有N個(gè)隊(duì)列芍锚。
扇出exchange是消息廣播路由的理想選擇。
因?yàn)樯瘸鰁xchange將消息的副本傳遞給綁定到它的每個(gè)隊(duì)列蔓榄，所以它的用例非常相似：
大型多人在線（MMO）游戲可以將其用于排行榜更新或其他全球活動(dòng)
體育新聞網(wǎng)站可以使用扇出exchange來近乎實(shí)時(shí)地向移動(dòng)客戶端分發(fā)分?jǐn)?shù)更新
分布式系統(tǒng)可以廣播各種狀態(tài)和配置更新
群聊可以使用扇出exchange在參與者之間分發(fā)消息（盡管AMQP沒有內(nèi)置的存在概念并炮，因此XMPP可能是更好的選擇）
扇出exchange可以用圖形表示如下：
主題exchange
主題基于消息路由密鑰與用于將隊(duì)列綁定到exchange的模式之間的匹配來將消息路由到一個(gè)或多個(gè)隊(duì)列。
主題交換類型通常用于實(shí)現(xiàn)各種發(fā)布/訂閱模式變體甥郑。
主題交換通常用于消息的多播路由
主題exchange具有非常廣泛的用例逃魄。
每當(dāng)問題涉及多個(gè)消費(fèi)者/應(yīng)用程序選擇性地選擇他們想要接收哪種類型的消息時(shí)，應(yīng)考慮使用主題exchange澜搅。
使用例子:
分發(fā)與特定地理位置相關(guān)的數(shù)據(jù)伍俘，例如銷售點(diǎn)
由多個(gè)工作人員完成的后臺(tái)任務(wù)處理邪锌，每個(gè)工作人員能夠處理特定的任務(wù)集
股票價(jià)格更新（以及其他類型的財(cái)務(wù)數(shù)據(jù)更新）
涉及分類或標(biāo)記的新聞更新（例如，僅針對(duì)特定運(yùn)動(dòng)或團(tuán)隊(duì)）
在云中協(xié)調(diào)不同類型的服務(wù)
分布式架構(gòu)/特定于操作系統(tǒng)的軟件構(gòu)建或打包癌瘾，每個(gè)構(gòu)建器只能處理一個(gè)體系結(jié)構(gòu)或操作系統(tǒng)
頭exchange
頭exchange設(shè)計(jì)用于在多個(gè)屬性上進(jìn)行路由觅丰，這些屬性更容易表示為消息頭而不是路由密鑰。
頭exchange忽略路由密鑰屬性妨退。
相反妇萄，用于路由的屬性取自headers屬性。
如果頭的值等于綁定時(shí)指定的值咬荷，則認(rèn)為消息是匹配的冠句。
可以使用多個(gè)頭將隊(duì)列綁定到頭exchange以進(jìn)行匹配。
在這種情況下幸乒，代理需要來自應(yīng)用程序開發(fā)人員的另一條信息懦底，即它是否應(yīng)該考慮與任何頭匹配的消息，還是所有頭罕扎？
這就是“x-match”綁定參數(shù)的用途聚唐。
當(dāng)“x-match”參數(shù)設(shè)置為“any”時(shí)，只需一個(gè)匹配的頭值就足夠了腔召。
或者拱层，將“x-match”設(shè)置為“all”，強(qiáng)制所有值必須匹配宴咧。
頭exchange可視為“直接exchange”根灯。
因?yàn)樗鼈兓陬^值進(jìn)行路由，所以它們可以用作直接exchange掺栅，其中路由密鑰不必是字符串;
例如烙肺，它可以是整數(shù)或散列（字典）。
隊(duì)列
AMQP 0-9-1模型中的隊(duì)列與其他消息和任務(wù)排隊(duì)系統(tǒng)中的隊(duì)列非常相似：它們存儲(chǔ)應(yīng)用程序使用的消息氧卧。
隊(duì)列與exchange共享一些屬性桃笙，但也有一些額外的屬性:
Name 名字
Durable（隊(duì)列將在代理重啟后繼續(xù)存在）
Exclusive（僅由一個(gè)連接使用，當(dāng)該連接關(guān)閉時(shí)將刪除隊(duì)列）
Auto-delete（至少有一個(gè)消費(fèi)者的的隊(duì)列在最后一個(gè)消費(fèi)者取消訂閱時(shí)將被刪除）
Arguments（可選;由插件和特定于代理的功能使用沙绝，例如消息TTL搏明，隊(duì)列長度限制等）
在可以使用隊(duì)列之前，必須聲明它闪檬。
聲明隊(duì)列將導(dǎo)致它創(chuàng)建（如果它尚不存在）星著。
如果隊(duì)列已經(jīng)存在并且其屬性與聲明中的屬性相同，則聲明將不起作用粗悯。
當(dāng)現(xiàn)有隊(duì)列屬性與聲明中的隊(duì)列屬性不同時(shí)虚循，將引發(fā)具有代碼406（PRECONDITION_FAILED）的通道級(jí)異常。
隊(duì)列名字
應(yīng)用程序可以選擇隊(duì)列名稱或要求代理為其生成名稱。
隊(duì)列名稱最多可包含255個(gè)字節(jié)的UTF-8字符横缔。
AMQP 0-9-1代理可以代表應(yīng)用程序生成唯一的隊(duì)列名稱铺遂。
要使用此功能，請(qǐng)將空字符串作為隊(duì)列名稱參數(shù)傳遞茎刚。
生成的名稱將返回給具有隊(duì)列聲明響應(yīng)的客戶端襟锐。
隊(duì)列名稱以“amq”開頭。保留供代理內(nèi)部使用膛锭。嘗試聲明具有違反此規(guī)則的名稱的隊(duì)列將導(dǎo)致帶有回復(fù)代碼403（ACCESS_REFUSED）的通道級(jí)異常粮坞。
隊(duì)列持久性
持久隊(duì)列持久存儲(chǔ)到磁盤，因此可以在代理重啟時(shí)繼續(xù)運(yùn)行泉沾。不持久的隊(duì)列稱為瞬態(tài)。并非所有場(chǎng)景和用例都要求隊(duì)列持久妇押。
隊(duì)列的持久性不會(huì)使路由到該隊(duì)列的消息持久跷究。
如果代理被刪除然后重新啟動(dòng)，則在代理啟動(dòng)期間將重新聲明持久隊(duì)列敲霍，但是俊马，只會(huì)恢復(fù)持久性消息。
綁定
綁定是exchange使用（除其他外）將消息路由到隊(duì)列的規(guī)則肩杈。
為了指示exchangeE將消息路由到隊(duì)列Q柴我，Q必須綁定到E.綁定可以具有某些exchange類型使用的可選路由密鑰屬性。
路由密鑰的目的是選擇發(fā)布到exchange的某些消息以路由到綁定隊(duì)列扩然。
換句話說艘儒，路由鍵的作用類似于過濾器。
用一個(gè)類比來說：
隊(duì)列就像你在紐約市的目的地
交易所就像JFK機(jī)場(chǎng)
綁定是從JFK到目的地的路線夫偶。
可以通過零種或多種方式實(shí)現(xiàn)它
擁有這一間接層可以實(shí)現(xiàn)使用直接發(fā)布到隊(duì)列不可能或非常難以實(shí)現(xiàn)的路由方案界睁，并且還可以消除開發(fā)人員必須執(zhí)行的一定數(shù)量的重復(fù)工作。
如果AMQP消息無法路由到任何隊(duì)列（例如兵拢，因?yàn)樗鼪]有發(fā)布到它的exchange的綁定）翻斟，它將被刪除或返回給發(fā)布者，具體取決于發(fā)布者設(shè)置的消息屬性说铃。
消費(fèi)者
除非應(yīng)用程序可以消費(fèi)消息访惜，否則將消息存儲(chǔ)在隊(duì)列中是沒用的。
在AMQP 0-9-1模型中腻扇，應(yīng)用程序有兩種方法可以執(zhí)行此操作：
向他們發(fā)送消息（“推送API”）
根據(jù)需要獲取消息（“拉取 API”）
使用“推送API”债热，應(yīng)用程序必須表明有興趣使用來自特定隊(duì)列的消息。
當(dāng)他們這樣做時(shí)幼苛，我們說他們注冊(cè)了一個(gè)消費(fèi)者阳柔，或者簡(jiǎn)單地說，他們訂閱了一個(gè)隊(duì)列蚓峦。
每個(gè)隊(duì)列可以有多個(gè)消費(fèi)者舌剂，或者注冊(cè)一個(gè)獨(dú)占消費(fèi)者（在消費(fèi)時(shí)排除隊(duì)列中的所有其他消費(fèi)者）济锄。
每個(gè)消費(fèi)者（訂閱）都有一個(gè)稱為消費(fèi)者標(biāo)簽的標(biāo)識(shí)符。它可用于取消訂閱郵件霍转。消費(fèi)者標(biāo)簽只是字符串荐绝。
消息確認(rèn)
消費(fèi)者應(yīng)用程序 - 接收和處理消息的應(yīng)用程序 - 有時(shí)可能無法處理單個(gè)消息或有時(shí)會(huì)崩潰。
網(wǎng)絡(luò)問題也可能導(dǎo)致問題避消。
這提出了一個(gè)問題：AMQP代理何時(shí)應(yīng)該從隊(duì)列中刪除消息低滩？
AMQP 0-9-1規(guī)范提出了兩種選擇：
代理向應(yīng)用程序發(fā)送消息后（使用basic.deliver或basic.get-ok AMQP方法）。
應(yīng)用程序發(fā)回確認(rèn)后（使用basic.ack AMQP方法）岩喷。
前一種選擇稱為自動(dòng)確認(rèn)模型恕沫，后一種稱為顯式確認(rèn)模型。
使用顯式模型纱意，應(yīng)用程序選擇何時(shí)發(fā)送確認(rèn)婶溯。
它可以在接收消息之后，或者在處理之前將其持久保存到數(shù)據(jù)存儲(chǔ)之后偷霉，或者在完全處理消息之后（例如迄委，成功獲取網(wǎng)頁，處理并將其存儲(chǔ)到某個(gè)持久性數(shù)據(jù)存儲(chǔ)中）类少。
如果消費(fèi)者在沒有發(fā)送確認(rèn)的情況下死亡叙身，則AMQP代理將其重新發(fā)送給另一個(gè)消費(fèi)者，或者如果當(dāng)時(shí)沒有消費(fèi)者硫狞，則代理在嘗試重新發(fā)送之前將等待至少一個(gè)消費(fèi)者注冊(cè)相同的隊(duì)列信轿。
拒絕消息
當(dāng)消費(fèi)者應(yīng)用程序收到消息時(shí)，該消息的處理可能成功也可能不成功残吩。
應(yīng)用程序可以通過拒絕消息向代理指示消息處理已經(jīng)失斅擦健（或者當(dāng)時(shí)無法完成）。
拒絕消息時(shí)世剖，應(yīng)用程序可以要求代理放棄或重新排隊(duì)定罢。
當(dāng)隊(duì)列中只有一個(gè)消費(fèi)者時(shí)，請(qǐng)確保不要通過一遍又一遍地拒絕和重新排隊(duì)來自同一消費(fèi)者的消息來創(chuàng)建無限的消息傳遞循環(huán)旁瘫。
Negative Acknowledgements
使用basic.reject AMQP方法拒絕郵件祖凫。
basic.reject有一個(gè)限制：無法拒絕多條消息，就像你可以使用確認(rèn)一樣酬凳。
但是惠况，如果你使用RabbitMQ，那么有一個(gè)解決方案宁仔。
RabbitMQ提供AMQP 0-9-1擴(kuò)展稠屠，稱為Negative Acknowledgements或nack。
預(yù)取消息
對(duì)于多個(gè)消費(fèi)者共享隊(duì)列的情況，能夠在發(fā)送下一個(gè)確認(rèn)之前指定每個(gè)消費(fèi)者可以一次發(fā)送多少消息是有用的权埠。
這可以用作簡(jiǎn)單的負(fù)載平衡技術(shù)榨了，或者如果消息傾向于批量發(fā)布，則可以提高吞吐量攘蔽。
例如龙屉，如果生產(chǎn)應(yīng)用程序由于其正在進(jìn)行的工作的性質(zhì)而每分鐘發(fā)送一次消息。
請(qǐng)注意满俗，RabbitMQ僅支持通道級(jí)預(yù)取計(jì)數(shù)转捕，而不支持基于連接或大小的預(yù)取。
消息屬性和有效負(fù)載
AMQP模型中的消息具有屬性唆垃。
有些屬性非常常見五芝，AMQP 0-9-1規(guī)范定義了它們，應(yīng)用程序開發(fā)人員不必考慮確切的屬性名稱辕万。
一些例子是
Content type
Content encoding
Routing key
Delivery mode (持久化與否)
Message priority
Message publishing timestamp
Expiration period
Publisher application id
AMQP代理使用了一些屬性枢步，但大多數(shù)屬性都可以通過接收它們的應(yīng)用程序進(jìn)行解釋。某些屬性是可選的蓄坏，稱為標(biāo)題价捧。它們類似于HTTP中的X-Header丑念。發(fā)布消息時(shí)設(shè)置消息屬性涡戳。
AMQP消息還具有有效載荷（它們攜帶的數(shù)據(jù)），AMQP代理將其視為不透明的字節(jié)數(shù)組脯倚。
代理不會(huì)檢查或修改有效載荷渔彰。
消息可能只包含屬性而沒有有效負(fù)載。
通常使用序列化格式（如JSON推正，Thrift恍涂，Protocol Buffers和MessagePack）來序列化結(jié)構(gòu)化數(shù)據(jù)，以便將其作為消息有效負(fù)載發(fā)布植榕。
AMQP對(duì)等體通常使用“內(nèi)容類型”和“內(nèi)容編碼”字段來傳達(dá)此信息再沧，但這僅限于慣例。
消息可以作為持久性發(fā)布尊残，這使得AMQP代理將它們保存到磁盤炒瘸。
如果重新啟動(dòng)服務(wù)器，則系統(tǒng)會(huì)確保收到的持久消息不會(huì)丟失寝衫。
簡(jiǎn)單地將消息發(fā)布到持久exchange或者它被路由到的隊(duì)列是持久的這一事實(shí)不會(huì)使消息持久化：這一切都取決于消息本身的持久性模式顷扩。
將消息發(fā)布為持久性會(huì)影響性能（就像數(shù)據(jù)存儲(chǔ)一樣，持久性會(huì)在性能上產(chǎn)生一定的成本）慰毅。
消息確認(rèn)
由于網(wǎng)絡(luò)不可靠且應(yīng)用程序失敗隘截，因此通常需要進(jìn)行某種處理確認(rèn)。有時(shí)只需要確認(rèn)已收到消息這一事實(shí)。有時(shí)婶芭，確認(rèn)意味著消息由消費(fèi)者驗(yàn)證和處理东臀，例如，驗(yàn)證為具有強(qiáng)制數(shù)據(jù)并持久保存到數(shù)據(jù)存儲(chǔ)或索引雕擂。
這種情況非常常見啡邑，因此AMQP 0-9-1具有稱為消息確認(rèn)（有時(shí)稱為acks）的內(nèi)置功能，消費(fèi)者可使用該功能來確認(rèn)消息傳遞和/或處理井赌。如果應(yīng)用程序崩潰（AMQP代理在連接關(guān)閉時(shí)注意到此情況）谤逼，如果預(yù)期確認(rèn)消息但AMQP代理未收到該消息，則該消息將被重新排隊(duì)（并且可能立即傳遞給另一個(gè)消費(fèi)者仇穗，如果有的話）存在）流部。
在協(xié)議中內(nèi)置確認(rèn)有助于開發(fā)人員構(gòu)建更強(qiáng)大的軟件。
AMQP 0-9-1方法
AMQP 0-9-1結(jié)構(gòu)是多種方法纹坐。方法是操作（如HTTP方法）枝冀，與面向?qū)ο缶幊陶Z言中的方法沒任何共同之處。AMQP方法分為幾類耘子。類只是AMQP方法的邏輯分組果漾。
讓我們來看看exchange類，一組與交易所操作相關(guān)的方法谷誓。
它包括以下操作：
exchange.declare
exchange.declare-ok
exchange.delete
exchange.delete-ok
上面的操作形成邏輯對(duì)：exchange.declare和exchange.declare-ok绒障，exchange.delete和exchange.delete-ok。
這些操作是“請(qǐng)求”（由客戶端發(fā)送）和“響應(yīng)”（由代理響應(yīng)上述“請(qǐng)求”而發(fā)送）捍歪。
連接
AMQP 0-9-1連接通常是長期存在的户辱。
AMQP 0-9-1是一個(gè)使用TCP進(jìn)行可靠傳遞的應(yīng)用程序級(jí)協(xié)議。
連接使用身份驗(yàn)證糙臼，可以使用TLS進(jìn)行保護(hù)庐镐。
當(dāng)應(yīng)用程序不再需要連接到服務(wù)器時(shí)，它應(yīng)該正常關(guān)閉其AMQP 0-9-1連接变逃，而不是突然關(guān)閉底層TCP連接必逆。
通道
某些應(yīng)用程序需要多個(gè)連接到代理。但是揽乱，不希望同時(shí)打開許多TCP連接名眉，因?yàn)檫@樣做會(huì)消耗系統(tǒng)資源并使配置防火墻變得更加困難。AMQP 0-9-1連接與可被視為“共享單個(gè)TCP連接的輕量級(jí)連接”的通道復(fù)用锤窑。
每個(gè)客戶端做的協(xié)議操作都發(fā)生在通道上.在一個(gè)特定的通道上的通信和其他通道上的通信是完全隔離的,因此每個(gè)協(xié)議方法都攜帶通道id(又名 通道數(shù)),一個(gè)用于客戶端和代理找出這個(gè)方法是哪個(gè)通道.
通道僅存在于連接的上下文中璧针，而不是單獨(dú)存在。當(dāng)連接關(guān)閉時(shí)渊啰，它上面的所有通道也是如此探橱。
對(duì)于使用多個(gè)線程/進(jìn)程進(jìn)行處理的應(yīng)用程序申屹，每個(gè)線程/進(jìn)程打開一個(gè)新通道并且不在它們之間共享通道是很常見的。
虛擬主機(jī)
為了使單個(gè)代理可以托管多個(gè)隔離的“環(huán)境”（用戶組隧膏，exchange哗讥，隊(duì)列等），AMQP包含虛擬主機(jī)（vhost）的概念胞枕。
它們類似于許多流行的Web服務(wù)器使用的虛擬主機(jī)杆煞，并提供AMQP實(shí)體所在的完全隔離的環(huán)境。
AMQP客戶端指定在AMQP連接協(xié)商期間要使用的vhost腐泻。
