訊息佇列MQ ，本質是個佇列，其最簡單的操作就是入隊和出隊，既按照程序決定何時何條件入隊，和何時何條件出隊。也就是說，遇到入隊系統和出隊系統的業務訴求不一致時的場景，就可以考慮是否用訊息佇列來實現了。可應用場景有很多，以下是幾個常見的場景和解釋。
一：非同步處理、應用解耦、分散式
場景：主業務對子業務的處理結果並不關心時。
案例：電商系統中訂單系統、物流系統、財務系統、操作日誌記錄系統之間的關係。
通俗解釋：小明是個蛋糕店員。他做好蛋糕後，放在櫥窗中，在對應訂單上標記‘已完成’，然後繼續做下一個蛋糕，並不關心蛋糕後續是怎麼賣出的，也不關心啥時候賣出。
實作：使用一個佇列的中間件或中間系統來存放幾個業務系統的共用部分，並獨立處理。可使用每個系統各自的獨立標記，對各系統的處理進度進行記錄。在所有系統完成操作後，進行出隊操作，或持久化儲存資料。
注意點：需要考慮中間資料的容災能力，當故障發生並復原時，確保業務流程可以復原。確保每個資料都可以正確地完成處理。
二：峰值處理
#場景：流量在各個時間點不均衡
案例：秒殺、搶購
解釋：小明製作蛋糕的時間比較長，訂單來到後先登記成一個清單，然後逐次按順序製作，訂單量過大時，會暫時掛出『已售完』的牌子。
實作： 使用單執行緒的工具將業務需求進行排隊處理。當業務請求達到閥值時，給予友善提示並拒絕使用者的需求。
注意點：對於消峰需求，可以高峰期掛出『暫時無法購買，請稍等』等提示，防止流量對後續業務的衝擊。對於秒殺等搶完即停的需求，需要考慮超額問題，可以添加一個名額計數器，或者在秒殺名額已滿員時，發放一個秒殺完成標記，後續處理程序檢測到完成標記後，再進行後續處理。 
三：送達保證
場景：內容需要逐條嚴格執行，並保證執行成功，執行不成功或中斷時，可以恢復
案例：銀行、財務類系統，需提升災難能力的系統
解釋：小明製作的蛋糕需要客戶驗貨簽收後，才可以繼續製作下一個蛋糕。
實作：入隊系統將業務需求寫入訊息佇列後，即進行下一次業務處理。後續處理程序將佇列內容逐條處理，處理完成後發放『完成許可』。訊息佇列中的內容，只有取得『完成許可』後，才可以從訊息佇列中刪除。
注意：重點考慮災難相關問題，如業務復原問題、重複處理問題。 
四：排序保證
場景：訊息佇列中的內容有嚴格的順序。
案例：搶號排隊等系統
解釋：小明製作蛋糕的順序需要嚴格按下單一順序來製作。
實作：入隊系統將內容逐條寫入訊息佇列，並依照單線排列，依照先進先出的順序來提出資料並進行後續處理。
注意點：需要使用單線程，保證只有一條生產線。 
五：擴展性
場景：採用發布-訂閱模式時，新增新的訂閱者
案例：註冊用戶後，在發送成功簡訊的模型中，追加一個發送email的功能
實現： 由多個消費者訂閱一個訊息的中間層，然後發布者將訊息發佈到中間層中。 訂閱了這個中間層的消費者均可以收到這個訊息，並進行後續處理。在這個結構中。如果想要新增一個訊息的後續處理元件 ，只需要將這個元件訂閱到中間層即可
注意點：確保業務之間沒有深度耦合，防止擴展時造成乾擾。 
以上就是訊息佇列比較常用的幾種場景，訊息佇列可以平覆系統之間的差異，提高系統穩定性，適用場景還有很多。
在訊息佇列媒體選擇時，建議同學們不用在一開始就一定要將條件和目標最大化，一定要以什麼樣的條件完善完美的解決問題，程式還是需要一個長久維護與優化的過程。
雖然Redis在高流量且需要大量持久化資料等情況下，效能下降還是很嚴重的，但是還是建議大家從Redis來學習隊列，在課程中僅是透過改流程理解隊列的應用場景和思路，任何線上專案都是不斷優化與完善的，如果想透過一套影片完善的解決所有的問題，對不起臣妾做不到，每個工作的需求和應用場景都不同所以在有不同需求時就根據具體需求進行完善。
在判斷佇列需求時候，需要判斷佇列條件應用時加入計數器欄位在每次壓入佇列時判斷目前佇列的長度數量，如果數量超過限定的秒殺數量不在進入佇列程式。
在實際使用時，並不需要刻意追求哪些地方需要新增訊息佇列。而應依照實際情況，在進行業務分離和解耦合，以及一些特殊訴求時合理地選擇運用。
相關推薦：
#以上是PHP中訊息佇列常見使用場景的詳細內容。更多資訊請關注PHP中文網其他相關文章！
