PHP中訊息佇列常見使用情境

Message Queue ，本質是個隊列，其最簡單的操作就是入隊和出隊，既按照程式決定何時何條件入隊，和何時何條件出隊。也就是說，遇到入隊系統和出隊系統的業務訴求不一致時的情境，就可以考慮是否用訊息佇列來實現了。可應用情境有很多，以下是幾個常見的情境和解釋。

一：非同步處理、應用解耦、分布式

情境：主業務對子業務的處理結果並不關心時。

案例：電商系統中訂單系統、物流系統、財務系統以及動作記錄記錄系統之間的關係。

通俗解釋：小明是個蛋糕店員。他做好蛋糕後，放在櫥窗中，在對應訂單上標記『已完成』，然後繼續做下一個蛋糕，並不關心蛋糕後續是怎麼賣出的，也不關心啥時候賣出。
實現：使用一個隊列的中介軟體或者中間系統來存放幾個業務系統的共用部分，並獨立進行處理。可以使用每個系統各自的獨立標記，對各系統的處理進度進行記錄。在所有系統均完成操作後，進行出隊操作，或者持久化儲存資料。

注意點：需要考慮中間資料的容災能力，當故障發生並恢複時，保證商務程序可以恢複。保證每條資料都可以正確地完成處理。

二：峰值處理

情境：流量在各個時間點不均衡

案例：秒殺、搶購

解釋：小明製作蛋糕的時間比較長，訂單來到後先登記成一個清單，然後逐次按順序製作，訂單量過大時，會暫時掛出『已售完』的牌子。

實現： 使用單線程的工具將業務需求進行排隊處理。當業務請求達到閥值時，給出友好提示並拒絕使用者的需求。

注意點：對於消峰需求，可以高峰期掛出『暫時無法購買，請稍等』等提示，防止流量對後續業務的衝擊。對於秒殺等搶完即停的需求，需要考慮超發問題，可以添加一個名額計數器，或者在秒殺名額已滿員時，發放一個秒殺完成標記，後續處理常式檢測到完成標記後，再進行後續處理。

三：送達保證

情境：內容需要逐條嚴格執行，並保證執行成功，執行不成功或者中斷時，可以恢複

案例：銀行、財務類系統，需提升容災能力的系統

解釋：小明製作的蛋糕需要客戶驗貨簽收後，才可以繼續製作下一個蛋糕。

實現：入隊系統將業務需求寫入訊息佇列後，即進行下一次業務處理。後續處理常式對隊列內容進行逐條處理，處理完成後發放『完成許可』。訊息佇列中的內容，只有取得『完成許可』後，才可以從訊息佇列中刪除。

注意點：重點考慮容災相關問題，如業務恢複問題、重複處理問題。

四：排序保證

情境：訊息佇列中的內容有嚴格的順序。

案例：搶號排隊等系統

解釋：小明製作蛋糕的順序需要嚴格按下單順序來製作。

實現：入隊系統將內容逐條寫入訊息佇列，並按單線排列，按先進先出的順序來提出資料並進行後續處理。

注意點：需要使用單線程，保證只有一條生產線。

五：擴充性

情境：採用發布-訂閱模式時，添加新的訂閱者
案例：註冊使用者後，發送成功簡訊的模型中，追加一個發送email的功能
實現： 由多個消費者訂閱一個訊息的中介層，然後發行者將資訊發布到中介層中。 訂閱了這個中介層的消費者均可以收到這個訊息，並進行後續處理。在這個結構中。如果想添加一個訊息的後續處理組件 ，只需要將這個組件訂閱到中介層即可
注意點：保證業務之間沒有深度耦合，防止擴充時造成幹擾。

以上就是訊息佇列比較常用的幾種情境，訊息佇列可以平覆系統之間的差異，提高系統穩定性，適用情境還有很多。

在訊息佇列介質選擇時，建議同學們不用在一開始就一定要將條件和目標最大化，一定要以什麼樣的條件完善完美的解決問題，程式還是需要一個長久維護與最佳化的過程。

雖然Redis在高流量且需要大量持久化資料等情況下，效能下降還是很嚴重的，但是還是建議大家從Redis來學習隊列，在課程中僅是通過改流程理解隊列的應用情境和思路，任何線上項目都是不斷最佳化與完善的，如果想通過一套視頻完善的解決所有的問題，對不起臣妾做不到，每個工作的需求和應用情境都不同所以在有不同需求時就根據具體需求進行完善。

在判斷隊列需求時候，需要判斷隊列條件應用時添加計數器欄位在每次壓入隊列時判斷當前隊列的長度數量，如果數量超過限定的秒殺數量不在進入隊列程式。

在實際使用時，並不需要刻意追求哪些地方需要添加訊息佇列。而應該按照實際情況，在進行業務分離和解耦合，以及一些特殊訴求時合理地選擇和運用。

相關推薦：

PHP訊息佇列詳解

PHP之訊息佇列實現及應用

php實現訊息佇列類執行個體分享