1、非同步處理：
減少等待時間，更快的返回處理結果，提高系統效能以及更好的使用者體驗。
fe: 在乙個秒殺系統中，可能需要如下幾步：風險控制，鎖定庫存，生成訂單，訊息通知以及統計資料，在未優化的情況下，使用者請求到達閘道器後進入服務端要至少
經歷這五個步驟，但是對於秒殺系統而言關鍵的步驟在於風險控制和鎖定庫存 後使用者的秒殺已經完成，所以後續的生成訂單，訊息通知，統計資料，這些不影響主要業務
流程的操作我們可以採用非同步的方式，來更快的處理使用者請求，從而也是伺服器端可以更多的處理秒殺請求。
2、流量控制（削峰填谷）：
當海量請求到伺服器端時會壓垮伺服器，所以此時可以使用訊息佇列。
fe：首先流程是這樣的：請求->閘道器->服務端，當海量請求達到閘道器（軟硬體負載均衡：軟體負載均衡nginx,支援十萬級併發；硬體負載均衡f5，支援百萬級併發）後，
所有的請求到達服務端，會壓垮服務端，所以在閘道器和伺服器端加一中間過程：訊息佇列。所有請求入佇列，此時不需要擔心 訊息佇列的儲存能力，當硬碟容量足夠時，可
無限儲存，之後伺服器端根據自己的消費能力去訊息佇列中獲取請求進行處理，達到保護後台服務的作用。
fe:流量控制可以採用令牌桶的形式，有令牌生成器，根據規定流量生成指定數量令牌，伺服器端獲取請求時，首先獲取令牌，拿到令牌後放開處理請求，沒有令牌則
不能進行請求處理
當然在做優化時也會有相應代價：呼叫鏈增長，增加響應時間；同步請求改為非同步請求，增加了系統的複雜度。 凡是有利便有弊，權衡專案所需。
3、服務解耦
在當下微服務橫行的時代，脫離的單體應用，乙個專案會根據不同的粒度拆分為幾十個甚至幾百個專案，當從幾個到幾十個再到幾百個時複雜度是以直線上公升的，各系統之間
的互相呼叫，在系統類圖中可以看見密密麻麻的連線，專案耦合在一起，所以此時可以使用訊息佇列進行解耦。而且當下游服務發生變化時，所有呼叫的上游服務都會發生變化，這個是
不允許的，所以在應用過程中，可以採用訊息佇列
4、分布式事務
通過訊息中介軟體，來保證分布式事物的最終一致性。這是一種比較提倡的解決方案，有利於服務之間解耦，雖然是非同步的，但基本上事物也是即時性的。
fe:將業務a的提交操作和傳送訊息的記錄 寫在同乙個事物中(把訊息傳送記錄在本地庫中)，然後業務b接收到訊息之後進行相應的操作，成功後，向a傳送成功通知。失敗則通知a，進行回滾。 當a中的訊息傳送不成功的時候，則會通過定時任務輪訓來進行傳送，從而保證訊息最終肯定可以到達b。 但是當a接收到b的成功通知後 應該刪除訊息記錄或者修改記錄狀態，但是突然a掛掉了，a就沒有及時修改本地訊息記錄，導致定時輪訓的時候會重發，如果此時b中業務不是冪等的則會出現問題，所以如何避免這種訊息重發呢？ 在b方也對訊息進行記錄，當a中傳送過來訊息後，b判斷訊息是否執行過，來避免這種問題
5、發布/訂閱者模式
訊息佇列的使用場景
知乎 假設使用者在你的軟體中註冊，服務端收到使用者的註冊請求後，它會做這些操作 校驗使用者名稱等資訊，如果沒問題會在資料庫中新增乙個使用者記錄 如果是用郵箱註冊會給你傳送一封註冊成功的郵件，手機註冊則會傳送一條簡訊 分析使用者的個人資訊，以便將來向他推薦一些志同道合的人，或向那些人推薦他 傳送給使用...
訊息佇列的使用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的差別是，並行的方式可以提高處理的時間。假設三個業務節點每個使用50毫秒鐘，不考慮網路等...
訊息佇列的使用場景
1非同步處理 場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。1 序列方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件，再傳送註冊簡訊。以上三個任務全部完成後，返回給客戶端。2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上...