按定義的順序處理一組相關的訊息，不需阻止對其他訊息組的處理。
背景
應用程式通常需要按照訊息到達的順序處理訊息序列，同時仍可以橫向擴充套件以處理增加的負載。 在分散式體系結構中，按順序處理這些訊息並不是很簡單，因為輔助角色可以獨立縮放，並且通常使用競爭性使用者模式單獨提取訊息。
例如，訂單跟蹤系統接收包含訂單的分類帳和對這些訂單的相關操作。 這些操作可能是建立訂單、向訂單中新增事務、修改過去的交易或刪除訂單。 在此係統中，必須按照先進先出 （FIFO） 方式執行操作，但只能在訂單級別執行操作。 不過，初始佇列接收多個訂單的包含多個訂單的交易，這可能是交錯的。
解決方案
將相關的訊息推送到佇列系統內的類別中，並讓佇列偵聽器鎖定並僅從一個類別（一次一個訊息）中請求。
一般順序保護模式如下所示：
順序保護模式示意圖
在佇列中，不同類別的訊息可能交錯，如下圖所示：
顯示交錯訊息的關係圖
問題和注意事項
在決定如何實現此模式時，請考慮以下幾點：
類別/縮放單位。 你可以向外擴充套件傳入訊息的哪個屬性？ 在訂單跟蹤方案中，此屬性為訂單 ID。
吞吐量。 目標訊息吞吐量是多少？ 如果它很高，則可能需要重新考慮 FIFO 要求。 例如，你是否可以強制執行開始/結束訊息、按時間排序，併發送一個批處理以便進行處理？
服務功能。 您選擇的訊息匯流排是否允許對佇列或佇列類別中的訊息進行一次性處理？
可進化性。 如何向系統新增新的訊息類別？ 例如，假定上面所述的會計系統是特定的客戶。 如果你需要加入新客戶，你是否可以擁有一組按客戶 ID 分配工作的分類帳處理器？
由於傳送訊息時出現可變網路延遲，因此使用者可能會因為訊息不按順序接收訊息。 請考慮使用序列號驗證排序。 你還可以在事務的最後一條訊息中包含一個特殊的 “序列結尾” 標誌。 流處理技術（例如 Spark 或 Azure 流分析）可以在某個時間範圍內按順序處理訊息。
何時使用此模式
在以下情況下使用此模式：
您有按順序到達並按順序處理的訊息。
傳入的訊息是或可 “分類的”，這種方式使類別成為系統的規模單位。
此模式可能不適用於以下情況：
極高的吞吐量方案 （數百萬條訊息/分鐘或秒） ，因為 FIFO 要求會限制系統可以執行的縮放。
