一.簡單模式
1.消息產生着§將消息放入隊列
2.消息的消費者(consumer) 監聽(while) 消息隊列,如果隊列中有消息,就消費掉,消息被拿走后,自動從隊列中刪除(隱患 消息可能沒有被消費者正確處理,已經從隊列中消失了,造成消息的丟失)應用場景:聊天(中間有一個過度的服務器;p端,c端)
二.工作模式(資源的競爭)
1.消息產生者將消息放入隊列消費者可以有多個,消費者1,消費者2,同時監聽同一個隊列,消息被消費?C1 C2共同爭搶當前的消息隊列內容,誰先拿到誰負責消費消息(隱患,高並發情況下,默認會產生某一個消息被多個消費者共同使用,可以設置一個開關(syncronize,與同步鎖的性能不一樣) 保證一條消息只能被一個消費者使用)
2.應用場景:紅包;大項目中的資源調度(任務分配系統不需知道哪一個任務執行系統在空閑,直接將任務扔到消息隊列中,空閑的系統自動爭搶)
三.publish/subscribe發布訂閱(共享資源)
1.X代表交換機rabbitMQ內部組件,erlang 消息產生者是代碼完成,代碼的執行效率不高,消息產生者將消息放入交換機,交換機發布訂閱把消息發送到所有消息隊列中,對應消息隊列的消費者拿到消息進行消費
2.相關場景:郵件群發,群聊天,廣播(廣告)
四.路由模式
1.消息生產者將消息發送給交換機按照路由判斷,路由是字符串(info) 當前產生的消息攜帶路由字符(對象的方法),交換機根據路由的key,只能匹配上路由key對應的消息隊列,對應的消費者才能消費消息;
2.根據業務功能定義路由字符串
3.從系統的代碼邏輯中獲取對應的功能字符串,將消息任務扔到對應的隊列中業務場景:error 通知;EXCEPTION;錯誤通知的功能;傳統意義的錯誤通知;客戶通知;利用key路由,可以將程序中的錯誤封裝成消息傳入到消息隊列中,開發者可以自定義消費者,實時接收錯誤;
五. topic 主題模式(路由模式的一種)
1.星號井號代表通配符
2.星號匹配不多不少恰好1個詞）,#匹配一個或多個詞
3.路由功能添加模糊匹配
4.消息產生者產生消息,把消息交給交換機
5.交換機根據key的規則模糊匹配到對應的隊列,由隊列的監聽消費者接收消息消費
RabbitMQ -交換機
fanout模式：
廣播式交換器類型（fanout）：該類交換器不分析所接收到消息中的Routing Key，默認將消息轉發到所有與該交換器綁定的隊列中去。廣播式交換器轉發效率最高，但是安全性較低，消費者應用程序可獲取本不屬於自己的消息。
direct模式：
直接式交換器類型（direct）：該類交換器需要精確匹配Routing Key與BindingKey，如消息的Routing Key = Cloud，那么該條消息只能被轉發至Binding Key = Cloud的消息隊列中去。直接式交換器的轉發效率較高，安全性較好，但是缺乏靈活性，系統配置量較大。
topic模式：
主題式交換器（Topic Exchange）：該類交換器通過消息的Routing Key與Binding Key的模式匹配，將消息轉發至所有符合綁定規則的隊列中。Binding Key支持通配符，其中“”匹配一個詞組，“#”匹配多個詞組（包括零個）。例如，Binding Key=“.Cloud.#”可轉發Routing Key=“OpenStack.Cloud.GD.GZ”、“OpenStack.Cloud.Beijing”以及“OpenStack.Cloud”的消息，但是對於Routing Key=“Cloud.GZ”的消息是無法匹配的。
1.生產者發送消息到交換機
2.交換機根據routingkey 轉發消息給隊列
3.消費者監控隊列，獲取隊列中信息
4.消費成功刪除隊列中的消息
headers模式：
根據消息的headers來匹配對應的隊列，在消息接收回調中指定headers， 可以是Map<String, Object>、String可變數組類型的keys等