我正在處理從現場設備接收消息的情況。這些消息已加上序列號，我需要按原始順序處理這些消息。消息很少會丟失，但並非不可能，所以我需要一個機制來處理它。訂單非常重要時缺少消息
我的實現建立在NServiceBus上，我正在利用「HandleCurrentMessageLater」功能將消息彈出到隊列後面，以防消息被亂序接收。
如果我最終收到序列中的下一條消息，那麼我可以處理積壓，這很有效。
在這種情況下，我有什麼選擇來處理丟失的消息？我的第一反應是實現某種老化算法，在一定數量的失敗嘗試或類似事件之後會增加序列號，但是必須這樣做的複雜性有點過分。
有沒有人遇到類似的問題，願意分享他們如何解決它？
感謝
這聽起來好像這是你需要從業務投入。是否有時間限制，在此之後，可以認爲該消息不可挽回地丟失？如果是這樣，那麼在這種情況下應該採取的商業行爲是什麼？如果該消息最終收到但超時後會發生什麼？
你可以用佐賀實現的那種情況。如果消息到達並且失序，那麼您仍然會調用HandleCurrentMessageLater，但是您還會請求超時，以便如果在業務批准的超時後這些條件仍然爲真，則可以運行補償操作，而其餘的可以處理備份的消息。
或者，可能的替代解決方案。您說您需要按原始順序處理郵件。你不會詳細討論這種現實生活的影響，但這聽起來像是一個高層次的業務需求，但不是技術要求。換句話說，這就是企業想要看到它的方式，但它不一定是它真正發生的方式。也許你可以正常處理按順序的消息，並增加一個值，指出收集到的數據有效的序列號。如果消息按順序到達，它們仍然可以進行軟處理，但序號不會遞增。
所以基本上你會收到消息1-5並正常處理它們。然後你會收到7-10（6已被跳過）並且你處理它們，但是ValidSequenceNumber仍然是5.然後當＃6到達時，你處理它，採取任何補償行動追上，並且ValidSequenceNumber現在是10。佐賀也是實施這種邏輯的好選擇。
謝謝大衛。我決定，我將使用更爲人工的方法來報告這種情況，這將允許我暫時手動修復它。我希望瞭解在實施自動化機制之前，多長時間，更重要的是爲什麼會發生這種情況。 –
+1「理解爲什麼」:-) –
如果您確實需要所有可靠傳輸的消息，並且您的傳輸通道不可靠，那麼您需要一個確認和重傳機制。這可能如下所示。
正常流動：
丟失消息：
這顯然需要雙向通信，具有從服務器到客戶端的傳輸通道。
該問題已經深入解決了保證順序傳輸的TCP協議。你可能想看看TCP重傳內部。
感謝Bernd，我們有一個這樣的機制。但在極端的條件下，我們可能仍然會失去一個信息例如，如果在設備上發生錯誤，並且消息根本不發送。許多事情可能會導致這種情況，比如設備的總功率損失等。 –
David Boike在使用NSB傳奇時有正確的答案。我想添加另一個選項。如果消息在短時間內產生，則設備可以使用NSB功能將多個邏輯消息分批到一個傳輸消息中。只需使用IBus的Send或Publish過載，該過載需要多個消息參數。這些批次保證按順序處理。
謝謝，我們正在按批處理消息，但無法按特定順序對所有消息進行批處理。這些信息是經過很長時間收集的，我們需要在信息可用時對其進行處理。這是一項業務要求。 –
如果一條消息丟失，您是否希望所有後續消息最終失敗？ –
我需要接受這個消息已經在某個時候丟失了，並且處理了我所擁有的數據。我們正在處理跟蹤信息，所以我們需要在所有情況下限制數據丟失。 –