前言：
rabbitmq最新的工作方式有7種 （3.8.9版本），以下展開介紹（翻譯）。
一、從AMQP0-9-1說起
https://www.rabbitmq.com/tutorials/amqp-concepts.html
什么是AMQP0-9-1
AMQP 0-9-1 (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming client applications to communicate with conforming messaging middleware brokers.
看下這個圖就好了，AMQP0-9-1就是一個高級消息隊列的協(xié)議，協(xié)議里規(guī)定了幾個部件及要求
image.png
如圖，消息發(fā)布者發(fā)布消息 先經(jīng)過exchange，然后根據(jù)routes規(guī)則，派發(fā)到一個或多個queue，
最后消費(fèi)者獲取queue中的消息（push或者是pull方式，rabbitMq貌似是push方式）。
其中，exchange+routes+queue合并稱之為broker（代理），也就是消息中間件主體。
對于具體部件的要求，比如針對exchange，有四種類型
image.png
有興趣的值上官網(wǎng)看類型間的差異。
二、7種不同的工作方式
1、Hello World 完全缺省模式
https://www.rabbitmq.com/tutorials/tutorial-one-java.html
image.png
最簡單的方式，缺省的exchenge 不設(shè)置routes，最原始消息隊列，工作中一般不會這么用，不再展開。
2、Work Queues 工作隊列模式
https://www.rabbitmq.com/tutorials/tutorial-two-java.html
image.png
消息產(chǎn)生之后放入一個隊列，兩個消費(fèi)者，消息被任意一個消費(fèi)者消費(fèi)之后就消失。
官方解釋場景，用來處理任務(wù)大耗時長的消息，可以理解為一個任務(wù)可以派發(fā)給任意一個人處理。
3、Publish/Subscribe 發(fā)布訂閱模式
https://www.rabbitmq.com/tutorials/tutorial-three-python.html
image.png
消息產(chǎn)生后，經(jīng)過exchanges派發(fā)到不同的隊列，給不同的客戶端消費(fèi)。
比如日志消息產(chǎn)生后，要分發(fā)給打印隊列和存儲隊列，最終完成控制臺的打印，和硬盤日志存儲兩個任務(wù)。
4、Routing 路由模式
在3的模式上增加了顯示使用路由的方式，如圖
https://www.rabbitmq.com/tutorials/tutorial-four-java.html
image.png
繼續(xù)接3種的場景，日志打印隊列需要打印全部日志，而日志存儲隊列可能只關(guān)注error的日志，這時候就可以根據(jù)route的規(guī)則，配置派發(fā)隊列的方式。
5、Topic 主題方式
https://www.rabbitmq.com/tutorials/tutorial-five-java.html
image.png
繼續(xù)4的場景，可以發(fā)現(xiàn)區(qū)別就是route的規(guī)則支持了模糊匹配（當(dāng)然exchange的type也要改為topic），
*表示1個或多個 #表示0個或多個。
場景如下，比如日志存儲隊列，希望存儲來自宿主機(jī)的全部信息+來自應(yīng)用容器的error信息，就可以用上。
小結(jié)：
以上1~5的場景，是層層遞進(jìn)的，1是完全缺省，5是全部配置都上。
狹義的消息隊列，用來解耦處理任務(wù)，用topic方式就最好了。
6、RPC 遠(yuǎn)程過程調(diào)用
https://www.rabbitmq.com/tutorials/tutorial-six-java.html
image.png
我覺得這個功能應(yīng)該是比較雞肋的，大家知道消息隊列也可以用來做rpc就好了，實現(xiàn)方式是消息產(chǎn)生之后，要調(diào)用消費(fèi)之后的回調(diào)，獲取回調(diào)的內(nèi)容。實現(xiàn)遠(yuǎn)程過程調(diào)用的功能。
顯示中的rpc很少用隊列來做吧。消息隊列天生就是用來做異步的，rpc有另外的方案。
7、Publisher Confirms 發(fā)布確認(rèn)？（不會翻譯）
https://www.rabbitmq.com/tutorials/tutorial-seven-java.html
這個是消息隊列的擴(kuò)展功能，目的是為了確認(rèn)消息有沒有被正確消費(fèi)，以topic方式（更低級的更是）為例，
消息被消費(fèi)者消費(fèi)了，從隊列中移除，而消費(fèi)者消費(fèi)消息的結(jié)果是不清楚的，可能拋異常了，也可能執(zhí)行了錯誤的業(yè)務(wù)表達(dá)了，這時候發(fā)布者是完全不知道的。
這個方式就消費(fèi)者消費(fèi)完之后 通知生產(chǎn)者，說消費(fèi)成功了，就這么回事。
如果不成功，也可以告知什么原因，或者期望生產(chǎn)者做什么（是重發(fā)，還是咋地）。
應(yīng)用場景肯定有的，我想到的分布式事務(wù)就可以用這個來處理。不過成本也在那，
一般用topic加上日志管理就好了。各位覺得呢
