今天基於rabbitmq的學習聊一下他的應用場景：
1、work_queue 工作佇列模式
例如我們有的時候有傳送簡訊的的服務，同事要傳送簡訊的時候比較多，那麼一台服務吃不消，這樣的話我們就可以使用這種模式來進行削峰填谷。如下圖
p是生產者 這個端要傳送訊息的量特別大（加入要傳送1000），並且傳送訊息不影響後邊的業務執行，這時候我們就使用mq來削峰。
c1和c2是相同的服務，都為簡訊服務，他們兩個單獨的處理能力為五百，這樣兩個加起來就有一千的量了（mq出來1000的訊息量綽綽有餘），而且這種模式下c1消費後c2就不會重複消費。
2、pub/sub 發布訂閱模式
參照下圖：
注意 此時紅色為佇列queue p是生產者 c是消費者 x是交換機
使用場景：fanout 廣播模式，當傳送同乙個訊息時候c1和c2為不同的服務，分別要根據同乙個訊息做不同的處理，比如說c1是為了日誌列印c2是為了日誌儲存到資料庫。這個時候才用廣播模式，起到應用解耦的作用。
3、routing模式 路由模式
注意：routing模式下交換機繫結佇列時要指定routing key，訊息被傳送時會**到對應的佇列中 ，還有交換機的型別要是direct
使用場景：下單後要對這個庫存進行修改，這時候可以為庫存系統專門設定乙個佇列，然後設定乙個key，注意這時候必須是下單成功。（看不明白就別較勁了，場景是我自己想的）
4、topics萬用字元模式
注意：其實當前模式可以實現發布訂閱模式，假設所有佇列繫結的都是*，那匹配時就類似於pub/sub模式了，實現routing模式，就是萬用字元寫的不那麼複雜就行，只是這種方式在設定routing key的時候更加的靈活
使用場景：上述的皆可用（本人沒有太多實戰經驗，鍵盤那選手，只是做下記錄）
amqp是什麼？高階訊息 佇列協議
amqp，即advanced message queuing protocol，乙個提供統一訊息服務的應用層標準高階訊息佇列協議，是應用層協議的乙個開放標準，為面向訊息的中介軟體設計。基於此協議的客戶端與訊息中介軟體可傳遞訊息，並不受客戶端/中介軟體不同產品，不同的開發語言等條件的限制。
未完待續。。。。
訊息中介軟體應用場景
訊息佇列中介軟體是分布式系統中重要的元件，主要實現非同步訊息，應用解耦，流量削峰及訊息通訊等功能。下面舉例說明在實際應用中訊息佇列是如何使用的。以使用者註冊，並且需要註冊郵件和簡訊為例。使用者註冊後，需要傳送註冊郵件和註冊簡訊。傳統的做法有兩種 序列和並行方式。如下圖所示 1 序列方式 將註冊資訊寫...
訊息中介軟體 使用場景
訊息佇列在實際應用中包括如下四個場景 具體場景 使用者使用qq相簿上傳一張，人臉識別系統會對該進行人臉識別，一般的做法是，伺服器接收到後，上傳系統立即呼叫人臉識別系統，呼叫完成後再返回成功，如下圖所示 該方法有如下缺點 人臉識別系統被調失敗，導致上傳失敗 延遲高，需要人臉識別系統處理完成後，再返回給...
訊息中介軟體的使用場景
一般認為，採用訊息傳送機制 訊息佇列 的中介軟體技術，進行資料交流，用在分布式系統的整合。解決分布式系統之間訊息的傳遞。電商場景 使用者下單減庫存，呼叫物流系統，系統擴充後服務化和業務拆分。系統互動，y一般用rpc 遠端過程呼叫 如果系統擴充到有幾十個介面，訊息中介軟體來解決問題。一 非同步處理 使...