共用方式為

重複資料偵測

  • 發行項

如果應用程式在傳送訊息後因嚴重錯誤而失敗，且重新啟動後的應用程式執行個體錯誤地認為先前的訊息傳遞並未發生，則後續的傳送會導致同樣的訊息在系統中出現兩次。

這也有可能是用戶端或網路層級在稍早發生錯誤，在通知未能成功返回用戶端的情況下，讓已傳送的訊息提交到佇列中。 這個案例會讓用戶端對傳送作業的結果產生疑慮。

透過讓寄件者重新傳送同樣的訊息，重複偵測能將這些情況下的疑慮排除，而佇列或主題則會捨棄任何重複的複本。

注意

基本層的服務匯流排不支援重複偵測。 標準和進階層支援重複偵測。 如需這些階層之間的差異，請參閱服務匯流排定價。

運作方式

對於在指定時間範圍內傳送到佇列或主題的所有訊息，啟用重複偵測有助於追蹤由應用程式控制的 MessageId。 如果任何已傳送的新訊息包含已在時間範圍內記錄下來的 MessageId，則系統便會將訊息回報為已接受 (傳送作業成功)，不過新傳送的訊息會立即遭到忽略或捨棄。 除了 MessageId 之外，系統不會考慮訊息的其他部分。

由應用程式控制識別碼是必要措施，唯有這樣才能讓應用程式將 MessageId 繫結至商務流程內容，以確保在發生失敗時可預料其將會進行重建。

對於在處理某些應用程式內容期間傳送多則訊息的商務流程，MessageId 可以是應用程式層級內容識別碼 (如訂單號碼) 和訊息主旨 (例如，12345.2017/payment) 的複合。

MessageId 永遠都可以是某個 GUID，但將識別碼錨定在商務程序中會產生可預測的重複性，這是有效使用重複偵測功能不可或缺的一環。

重要

  • 啟用資料分割時，MessageId+PartitionKey 會用來判斷唯一性。 啟用工作階段時，分割區索引鍵和工作階段識別碼必須相同。
  • 停用資料分割 (預設) 時，MessageId 僅用來判斷唯一性。
  • 如需 SessionId、PartitionKey 和 MessageId 的詳細資訊，請參閱使用分割區索引鍵。
  • 使用資料分割和傳送批次訊息時，您應該確定它們不包含任何資料分割識別屬性。 由於重複資料刪除依賴明確設定訊息識別碼來判斷唯一性，因此不建議使用重複資料刪除和批處理搭配資料分割。

注意

排程訊息會包含在重複偵測中。 因此，如果傳送排程訊息，然後傳送重複的非排程訊息，則會卸除非排程訊息。 同樣地，如果傳送非排程訊息，然後傳送重複的排程訊息，則會卸除排程訊息。

重複偵測時段大小

除了僅啟用重複偵測之外，您也可以在保留訊息識別碼期間，設定重複偵測歷程記錄時間範圍的大小。 針對佇列和主題，此值預設為 10 分鐘，而最小值為 20 秒，最大值為 7 天。

啟用重複偵測和時間範圍的大小會直接影響佇列 (和主題) 輸送量，因為所有記錄下來的訊息識別碼，都必須與新提交的訊息識別碼進行比對。

維持較短的時間範圍，意味著要保留及比對的訊息識別碼比較少，對輸送量的影響也比較小。 對於需要重複偵測的高輸送量實體，您應盡可能縮短時間範圍。

下一步

您可以使用 Azure 入口網站、PowerShell、CLI、Resource Manager 範本、.NET、Java、Python 和 JavaScript 來啟用重複訊息偵測。 如需詳細資訊，請參閱啟用重複訊息偵測。

如果用戶端程式代碼無法使用之前相同的 MessageId 重新提交訊息時，請務必設計可以安全重新處理的訊息。 本等冪相關的部落格文章說明如何執行這項操作的各種技術。

請以您所選擇的語言嘗試各式範例，以探索 Azure 服務匯流排的功能。

請在此處查看舊版 .NET 和 Java 用戶端程式庫的範例：

在 2026 年 9 月 30 日，我們將淘汰不符合 Azure SDK 準則的 Azure 服務匯流排 SDK 程式庫 WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus 和 com.microsoft.azure.servicebus。 我們也將結束 SBMP 通訊協定的支援，因此您將無法在 2026 年 9 月 30 日之後再使用此通訊協定。 請在該日期之前移轉至最新的 Azure SDK 程式庫，該程式庫提供重要的安全性更新和改進的功能。

雖然較舊的程式庫仍可在 2026 年 9 月 30 日之後使用，但它們將不再收到 Microsoft 的官方支援和更新。 如需詳細資訊，請參閱支援淘汰公告。