1、簡單模式
helloworld
注釋：p:生產者（傳送資料） 佇列：儲存資料（訊息緩衝器） c:消費者（獲取資料）
生產者消費者均為應用程式。
2、工作佇列
注釋：預設情況下，rabbitmq將按順序將每條訊息傳送給下乙個消費者。平均而言，每個消費者將獲得相同數量的訊息。這種分發訊息的方式稱為迴圈法。與三個或更多工人一起嘗試。
手動確認：我們通過autoack = true 標誌明確地將它們關閉。一旦我們完成任務，就應該將此標誌設定為false並從工作人員傳送適當的確認。若忘記返回確認會造成訊息無法釋放，記憶體堆積。
訊息持久化：資料寫入磁碟，資料不易丟失（佇列和訊息都標記為持久）
訊息非持久化：資料寫入記憶體，資料儲存速度快
能者多勞
3、發布訂閱
基本上，發布的訊息將被廣播給所有接收者。
注釋：p:生產者（傳送資料） x:交換機 佇列：儲存資料（訊息緩衝器） c:消費者（獲取資料）
rabbitmq中訊息傳遞模型的核心思想是生產者永遠不會將任何訊息直接傳送到佇列。實際上，生產者通常甚至不知道訊息是否會被傳遞到任何佇列。
四種exchanges型別：direct, topic, headers and fanout
發布訂閱用的交換機型別為fanout
4、路由
交換機型別：direct
直接交換背後的路由演算法很簡單 - 訊息進入佇列，其 繫結金鑰與訊息的路由金鑰完全匹配。
5、主題
交換機型別：topic
傳送到主題交換的訊息不能具有任意 routing_key - 它必須是由點分隔的單詞列表。單詞可以是任何內容，但通常它們指定與訊息相關的一些功能。一些有效的路由金鑰示例：「 stock.usd.nyse 」，「 nyse.vmw 」，「 quick.orange.rabbit 」。路由金鑰中可以包含任意數量的單詞，最多可達255個位元組。
繫結金鑰也必須採用相同的形式。主題交換背後的邏輯 類似於直接交換- 使用特定路由金鑰傳送的訊息將被傳遞到與匹配繫結金鑰繫結的所有佇列。但是，繫結鍵有兩個重要的特殊情況：
6、遠端過程呼叫（rpc）
使用rabbitmq構建rpc系統：客戶端和可伸縮的rpc伺服器。由於我們沒有任何值得分發的耗時任務，我們將建立乙個返回fibonacci數字的虛擬rpc服務。
rpc將這樣工作：
對於rpc請求，客戶端傳送帶有兩個屬性的訊息： replyto，設定為僅為請求建立的匿名獨佔佇列;以及correlationid，設定為每個請求的唯一值。
請求被傳送到rpc_queue佇列。
rpc worker（aka：server）正在等待該佇列上的請求。當出現請求時，它會執行該作業，並使用來自replyto欄位的佇列將帶有結果的訊息傳送回客戶端。
客戶端等待回覆佇列上的資料。出現訊息時，它會檢查correlationid屬性。如果它與請求中的值匹配，則返回對應用程式的響應。
設計模式六大模式
定義 就乙個類而言，應該僅有乙個引起它變化的原因 否則類應該被拆分 分析 1.核心 控制類的粒度大小，將物件解耦，提高其內聚性。定義 軟體實體 類 模組 函式等 應該可以擴充套件，但是不可修改。分析 1.兩個特徵 對於擴充套件是開放的 open for extension 對於更改是封閉的 clos...
設計模式 六大設計原則
剛剛結束設計模式學習時，感覺哪哪的抓不住重點，雖然之前師傅給勾了寫比較重要的設計模式，但是給我的感覺設計模式怎麼全都乙個樣子。通過對一些文章的瀏覽，簡單的對設計原則總結了一下。設計模式，就是設計範例。是經典問題的解決方案，是可以讓學習者舉一反三的，有研究價值 有交流價值的例子。設計模式的本質是物件導...
設計模式 六大設計原則
solid s 單一職責原則 o 開放封閉原則 l 黎克特制代換原則 i 介面隔離原則 d 依賴倒轉原則 故事 手機拍攝ufo 定義 就乙個類而言，應該僅有乙個引起它變化的原因。通俗講就是我們不要讓乙個類承擔過多的職責。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或...