遵循AMPQ協議的客戶端可以通過消息中間件相互通信。這樣客戶端可以用不同的開發語言實現，相互之間沒有很強的依賴性，降低了客戶端的復雜度，提高了開發效率，也有利於後期的維護。
AMQP的模型框架如下:
RabbitMQ是AMQP協議的開源實現。架構模型也可以用下圖表示:
如上圖，簡單模式，單發布者，單隊列，單消費者。
如上圖，工作模式
多個消費者*** * *使用壹個隊列的消息。
在這種模式下，rabbitMQ會自動做負載均衡，向所有消費者發送消息輪詢，即壹條消息只能被壹個消費者獲取。
如上圖，發布/訂閱發布訂閱模式(廣播模式)。
與前兩種模式相比，多了壹個交換(類型fanout)。消息首先被發送到交換，然後交換被分別發送到所有相應的隊列。消費者訂閱他自己的隊列，並在他訂閱的隊列上使用消息。
應用場景示例，如下圖所示:
比如網購和支付成功後通知用戶的方式有很多，app推送、短信、郵件等等。
消息到達後由exchange發送到三個隊列(app push q，SMS q，email_q)。
之後，app推送服務、短信通知服務和郵件通知服務從其訂閱隊列中獲取消息，通知用戶支付成功。
如上圖，交換類型設置為直接。
此時，消息中的rountingKey與交換中的bindingKey相匹配。如果相等，它們將被發送到相應的隊列。如果它們與bindingKey不匹配，消息將被丟棄。
應用場景示例，如下圖所示:
例如，服務生成的日誌有很多種，如error、info、debuf等。，而我們的需求只是想把錯誤類型的日誌寫到磁盤上，所以可以用路由方式把錯誤日誌路由到錯誤隊列，然後相應的寫磁盤服務獲取消息，寫到磁盤上。
如上圖，交流類型是話題。與第四種模式相比，相同點是都是按照rountingKey匹配，不同點是話題模式支持模糊匹配。