在大多數應用中，可通過訊息服務中介軟體來提公升系統非同步通訊，擴充套件解耦能力。比如，非同步處理：以使用者註冊為例：首先將使用者的註冊資訊寫入資料庫，然後給使用者傳送郵件，並且發一封簡訊。第一種方法：按照以前的同步方式，寫入資料庫調發郵件方法，發完郵件調發簡訊方法，每個需要50毫秒，算上寫入資料庫，就需要150毫秒，也就是150毫秒之後響應使用者請求，這樣就很慢了。我們可以用第二種方法：寫入資料庫之後，採用多執行緒的方式，同時傳送郵件和傳送簡訊，這樣只需要100毫秒就行。這樣也還是太慢了。我們思考第三種方法：訊息佇列模式，當使用者將註冊資訊寫進資料庫之後，給中介軟體（訊息佇列）傳送乙個訊息，只要寫入訊息佇列，就立即響應使用者。如果寫入訊息佇列只需要5毫秒的話，這樣就只需要55毫秒使用者就能獲得響應，遠遠比第一第二種方法節省很多時間。待訊息寫入佇列之後，發郵件和發簡訊採用非同步讀取訊息並處理訊息的方式，自己去後台處理訊息就行了。
場景二：應用解耦：
比如現在，有訂單系統和庫存系統，使用者下了乙個訂單，如果這兩個系統在乙個服務中，每個訂單都去呼叫庫存系統，會瞬間積壓大量的互相呼叫和連線數，很容易造成服務掛掉或卡死。那麼，如果引入訊息佇列就很方便了。使用者下完訂單之後，然後給訊息佇列傳送乙個訊息，然後庫存系統去訊息佇列讀取並處理訊息，不用等庫存系統處理完就響應使用者，這樣就變得快多了。（備註，後面會介紹邊界情況，比如，對庫存系統校驗某乙個商品還有沒有等等）。
場景三：流量x削峰：
我們常見的秒殺，如果瞬間有100萬個使用者請求，給訊息列表設定定長，比如設定10萬個請求。就看哪10萬個請求先進入訊息佇列，後面90萬個請求進入訊息佇列之後，立即駁回，告訴使用者秒殺失敗。10萬個最先進入佇列的響應使用者，秒殺成功。後台業務處理系統，就只需要讀取並處理這10萬個請求。這樣就完美的實現了秒殺的需求。
rabbitmq 應用場景
rabbitmq，或者說amqp解決了什麼問題，或者說它的應用場景是什麼？對於乙個大型的軟體系統來說，它會有很多的元件或者說模組或者說子系統或者 subsystem or component or submodule 那麼這些模組的如何通訊？這和傳統的ipc有很大的區別。傳統的ipc很多都是在單一系...
RabbitMQ的應用場景
1.非同步處理 使用者註冊後，需要發註冊郵件和註冊簡訊，傳統的方式 序列和並行。序列 使用者註冊資訊寫入資料庫 傳送郵件 傳送簡訊 註冊成功，使用者使用 並行 使用者註冊資訊寫入資料庫 傳送郵件 傳送簡訊 註冊成功，使用者使用 因為郵件和簡訊並不是註冊所必需的，即使不接收郵件和簡訊，使用者也可以進行...
RabbitMQ的幾種應用場景
1.a關注b，b傳送一條動態，a要能收到推送，或者要朋友圈有顯示 2.併發寫資料庫的時候 可以先放mq佇列,然後再寫資料 比如遊戲 同時使用多執行緒 3.其實很多地方都可以用訊息佇列，只要你想用基本都能用上，就看需不需要，如果是指普通的小使用者量，只需要直接請乙個新的執行緒跑就可以了 4.還有就是日...