Duplikálás észlelése

Ha egy alkalmazás egy üzenet elküldése után azonnal végzetes hiba miatt meghiúsul, és az újraindult alkalmazáspéldány tévesen úgy véli, hogy az előző üzenet kézbesítése nem történt meg, a későbbi küldés ugyanazt az üzenetet kétszer is meg fog jelenni a rendszerben.

Előfordulhat az is, hogy az ügyfél vagy a hálózat szintjén hiba lép fel egy pillanattal korábban, és egy elküldött üzenet véglegesítése az üzenetsorba, és a nyugtázás nem lett sikeresen visszaadva az ügyfélnek. Ez a forgatókönyv kétségeket hagy az ügyfél számára a küldési művelet eredményével kapcsolatban.

A duplikátumészlelés ezen helyzetekből kiveszi a kételyeket azáltal, hogy engedélyezi a feladónak ugyanazt az üzenetet, és az üzenetsor vagy a témakör elveti az ismétlődő másolatokat.

Megjegyzés:

A Service Bus alapszintje nem támogatja a duplikált észlelést. A standard és prémium szintek az ismétlődések észlelését is támogatják. A szintek közötti különbségekért tekintse meg a Service Bus díjszabását.

How it works

Az ismétlődések észlelésének engedélyezése segít nyomon követni az alkalmazás által vezérelt MessageId tulajdonságot az összes üzenet esetében, amelyet egy adott időablakban egy üzenetsorba vagy témakörbe küldtek. Ha az időablakban naplózott új üzenetet küld MessageId a rendszer, az üzenet elfogadottként lesz jelentve (a küldési művelet sikeres), de az újonnan elküldött üzenetet a rendszer azonnal figyelmen kívül hagyja és elveti. A rendszer csak a MessageId tulajdonságot veszi figyelembe, az üzenet egyéb részeit nem.

Az azonosító alkalmazásvezérlése elengedhetetlen, mivel csak ez teszi lehetővé az alkalmazás számára, hogy egy üzleti folyamat környezetéhez kösse MessageId , amelyből hiba esetén kiszámíthatóan rekonstruálható.

Az olyan üzleti folyamatok esetében, amelyekben egy alkalmazáskörnyezet kezelése során több üzenetet is küldenek, az MessageId alkalmazásszintű környezet azonosítójának összetettsége lehet, például egy megrendelési szám, valamint az üzenet tárgya, például 12345.2017/payment.

Az MessageId azonosító mindig lehet VALAMILYEN GUID, de az azonosító üzleti folyamathoz való rögzítése kiszámítható megismételhetőséget eredményez, ami az ismétlődő észlelési funkció hatékony használatához szükséges.

Fontos

  • Ha a particionálás engedélyezve van, MessageId+PartitionKey az egyediség meghatározására szolgál. Amikor a munkamenetek engedélyezve vannak, a partíciókulcsnak és a munkamenet-azonosítónak meg kell egyeznie.
  • Ha a particionálás le van tiltva (alapértelmezett), csak MessageId az egyediség meghatározására szolgál.
  • További információ a SessionIdpartíciókulcsokról PartitionKeyés MessageIda partíciókulcsokról.

Megjegyzés:

Az ütemezett üzenetek a duplikált észlelés részét képezik. Ezért ha ütemezett üzenetet küld, majd ismétlődő, nem ütemezett üzenetet küld, a rendszer elveti a nem ütemezett üzenetet. Hasonlóképpen, ha nem ütemezett üzenetet, majd ismétlődő ütemezett üzenetet küld, a rendszer elveti az ütemezett üzenetet.

Duplikált észlelési ablak mérete

A duplikált észlelés engedélyezésén kívül konfigurálhatja az ismétlődő észlelési előzmények időablakának méretét is, amely alatt az üzenetazonosítók megmaradnak. Ez az érték az üzenetsorok és témakörök esetében alapértelmezés szerint 10 perc, amelynek minimális értéke 20 másodperc és legfeljebb 7 nap.

Az ismétlődő észlelés és az ablak méretének engedélyezése közvetlenül befolyásolja az üzenetsor (és a témakör) átviteli sebességét, mivel az összes rögzített üzenetazonosítónak meg kell egyeznie az újonnan elküldött üzenetazonosítóval.

Az ablak kis méretben tartása azt jelenti, hogy kevesebb üzenetazonosítót kell megőrizni és egyeztetni, és az átviteli sebesség kevésbé lesz hatással. A duplikált észlelést igénylő nagy átviteli sebességű entitások esetében az ablakot a lehető legkisebbre kell hagynia.

Következő lépések

Az ismétlődő üzenetészlelést az Azure Portal, a PowerShell, a parancssori felület, a Resource Manager-sablon, a .NET, a Java, a Python és a JavaScript használatával engedélyezheti. További információ: Ismétlődő üzenetészlelés engedélyezése.

Azokban az esetekben, amikor az ügyfélkód nem tud újból elküldeni egy üzenetet ugyanazzal a MessageId azonosítóval , mint korábban, fontos, hogy biztonságosan újra feldolgozható üzeneteket tervezzen. Ez a blogbejegyzés az idempotencia leírja a különböző technikákat, hogyan kell csinálni.

Az Azure Service Bus funkcióinak megismeréséhez próbálja ki az Ön által választott nyelven elérhető mintákat.

A régebbi .NET- és Java-ügyfélkódtárak mintáit itt találja:

2026. szeptember 30-án kivonjuk az Azure Service Bus SDK-kódtárakat a WindowsAzure.ServiceBus, a Microsoft.Azure.ServiceBus és a com.microsoft.azure.servicebus kódtárakból, amelyek nem felelnek meg az Azure SDK irányelveinek. Az SBMP protokoll támogatását is megszüntetjük, így 2026. szeptember 30. után már nem használhatja ezt a protokollt. Migrálás a legújabb Azure SDK-kódtárakba, amelyek kritikus fontosságú biztonsági frissítéseket és továbbfejlesztett képességeket kínálnak ezen dátum előtt.

Bár a régebbi kódtárak 2026. szeptember 30-tól továbbra is használhatók, a Microsoft már nem kap hivatalos támogatást és frissítéseket. További információkért lásd a támogatási nyugdíjazási bejelentést.