Azure Service Bus: Ablauf (TTL) von Nachrichten

  • Artikel

Die Nutzlast in einer Nachricht oder die in einer Nachricht an einen Empfänger übermittelten Befehle/Anforderungen unterliegen fast immer einer Form von Ablauffrist auf Anwendungsebene. Nach Ablauf einer solchen Frist wird der Inhalt nicht mehr zugestellt oder der gewünschte Vorgang nicht mehr ausgeführt.

Für Entwicklungs- und Testumgebungen, in denen Warteschlangen und Themen häufig im Rahmen von Teilläufen von Anwendungen oder Anwendungsteilen verwendet werden, ist es auch wünschenswert, dass nicht zugestellte Testnachrichten automatisch gesammelt werden, damit der nächste Testlauf davon unbeeinflusst starten kann.

Hinweis

Wenn Sie noch nicht mit den Service Bus-Konzepten vertraut sind, lesen Sie Service Bus-Konzepte und Service Bus-Warteschlangen, -Themen und -Abonnements.

Der Ablauf jeder einzelnen Nachricht kann durch das Festlegen der Systemeigenschaft time-to-live gesteuert werden, die eine relative Dauer angibt. Der Ablauf wird zu einem absoluten Zeitpunkt, an dem die Nachricht in die Warteschlange der Entität gestellt wird. Zu diesem Zeitpunkt nimmt die Eigenschaft expires-at-utc den Wert enqueued-time-utc + time-to-live an. Die Einstellung für die Gültigkeitsdauer (time-to-live, TTL) einer im Broker gespeicherten Nachricht wird nicht erzwungen, wenn keine Clients aktiv lauschen.

Nach Ablauf des expires-at-utc-Zeitpunkts können Nachrichten nicht mehr abgerufen werden. Die Ablaufzeit wirkt sich nicht auf Nachrichten aus, die momentan für die Zustellung gesperrt sind. Diese Nachrichten werden weiterhin normal behandelt. Wenn die Sperre abläuft oder die Nachricht abgebrochen wird, tritt der Ablauf sofort in Kraft. Solange die Nachricht gesperrt ist, kann die Anwendung möglicherweise im Besitz einer Nachricht sein, die abgelaufen ist. Ob die Anwendung bereit ist, mit der Verarbeitung fortzufahren oder ob die Nachricht abgebrochen wird, bleibt dem Implementierer überlassen.

Eine extrem niedrige Gültigkeitsdauer (TTL) im Bereich von Millisekunden oder Sekunden kann dazu führen, dass Nachrichten ablaufen, bevor Empfängeranwendungen diese empfangen können. Erwägen Sie die höchste Gültigkeitsdauer, die für Ihre Anwendung funktioniert.

Hinweis

Für geplante Nachrichten geben Sie die Zeit an, zu der die Nachricht in der Warteschlange zum Abruf bereitstehen soll. Der Zeitpunkt, zu dem die Nachricht an Service Bus gesendet wird, unterscheidet sich von dem Zeitpunkt, zu dem die Nachricht in die Warteschlange eingereiht wird. Die Ablaufzeit der Nachricht hängt vom Zeitpunkt der Einreihung in die Warteschlange ab, nicht von dem Zeitpunkt, zu dem die Nachricht an Service Bus gesendet wird. Daher ist expires-at-utc immer noch Warteschlangeneinreihungszeit + Time-To-Live.

Wenn Sie beispielsweise ScheduledEnqueueTimeUtc auf 5 Minuten ab UtcNow und TimeToLive auf 10 Minuten festlegen, läuft die Nachricht nach 5 + 10 = 15 Minuten ab. Die Nachricht wird nach 5 Minuten in die Warteschlange eingereiht und der 10-Minuten-Zähler beginnt ab diesem Zeitpunkt.

Ablauf auf Entitätsebene

Alle Nachrichten, die in eine Warteschlange oder an ein Thema gesendet werden, unterliegen einer Standardablaufzeit, die auf Entitätsebene festgelegt wird. Sie kann auch im Portal während der Erstellung festgelegt und später angepasst werden. Die Standardablaufzeit wird für alle an die Entität gesendeten Nachrichten verwendet, bei denen time-to-live nicht explizit festgelegt ist. Die Standardablaufzeit dient auch als Obergrenze für den time-to-live-Wert. Nachrichten, die eine längere time-to-live-Ablaufzeit als der Standardwert haben, werden automatisch an den time-to-live-Standardnachrichtenwert angepasst, bevor sie in die Warteschlange eingereiht werden.

Hinweis

  • Der Standardwert für die Gültigkeitsdauer (Time-To-Live, TTL) für eine im Broker gespeicherte Nachricht ist der größte mögliche Wert für eine ganze 64-Bit-Zahl mit Vorzeichen, wenn nichts anderes angegeben ist.
  • Für Messagingentitäten (Warteschlangen und Themen) ist die Standardablaufzeit ebenfalls der größte mögliche Wert für eine ganze 64-Bit-Zahl mit Vorzeichen bei den Service Bus-Dienstebenen „Standard“ und „Premium“. Im Tarif Basic beträgt die Standardablaufzeit 14 Tage (dies ist auch der Höchstwert).
  • Wenn das Thema einen kleineren TTL-Wert als das Abonnement angibt, wird der TTL-Wert des Themas angewendet.

Abgelaufene Nachrichten können optional in eine Warteschlange für unzustellbare Nachrichten verschoben werden. Sie können diese Einstellung programmgesteuert oder mithilfe des Azure-Portals konfigurieren. Wenn die Option deaktiviert bleibt, werden abgelaufene Nachrichten verworfen. Abgelaufene Nachrichten, die in die Warteschlange für unzustellbare Nachrichten verschoben werden, können durch die Auswertung der dead-letter reason-Eigenschaft, die der Broker in den Benutzereigenschaften speichert, von anderen unzustellbaren Nachrichten unterschieden werden.

Wenn die Nachricht vor dem Ablaufen geschützt ist, solange sie gesperrt und das Flag für die Entität festgelegt ist, wird die Nachricht in die Warteschlange für unzustellbare Nachrichten verschoben, sobald die Sperre aufgehoben wird oder abläuft. Sie wird jedoch nicht verschoben, wenn die Nachricht erfolgreich verarbeitet wurde. Dann wird davon ausgegangen, dass die Anwendung sie trotz des nominalen Ablaufs erfolgreich abgearbeitet hat. Weitere Informationen zu Nachrichtensperren und zur Abwicklung finden Sie unter Nachrichtenübertragungen, Sperren und Abwicklung.

Die Kombination aus time-to-live und automatischer (und transaktionaler) Funktion für unzustellbare Nachrichten bei Ablauf ist ein wertvolles Instrument, um Vertrauen bei der Frage zu schaffen, ob ein Auftrag, der einem Handler oder einer Gruppe von Handlern innerhalb einer Frist erteilt wurde, bei Erreichen der Frist zur Verarbeitung abgerufen wird.

Stellen Sie sich beispielsweise eine Website vor, die Aufträge zuverlässig in einem Back-End mit eingeschränkter Skalierung ausführen muss, und bei der es gelegentlich zu Datenverkehrsspitzen kommt oder die von Verfügbarkeitszeiträumen dieses Back-Ends isoliert werden soll. Im Regelfall verschiebt der serverseitige Handler für die übermittelten Benutzerdaten die Informationen in eine Warteschlange und erhält anschließend eine Antwort, die die erfolgreiche Verarbeitung der Transaktion in einer Antwortwarteschlange bestätigt. Wenn es eine Datenverkehrsspitze gibt und der Back-End-Handler seine Backlogelemente nicht rechtzeitig verarbeiten kann, werden die abgelaufenen Aufträge an die Warteschlange für unzustellbare Nachrichten zurückgegeben. Der interaktive Benutzer kann benachrichtigt werden, dass der angeforderte Vorgang etwas länger als gewöhnlich dauert. Die Anforderung kann dann in eine andere Warteschlange für einen Verarbeitungspfad gestellt werden, woraufhin das endgültige Verarbeitungsergebnis per E-Mail an den Benutzer gesendet wird.

Ablauf für sitzungsfähige Entitäten

Für sitzungsfähige Warteschlangen oder Themenabonnements werden Nachrichten auf Sitzungsebene gesperrt. Wenn die TTL für eine der Nachrichten abläuft, werden alle Nachrichten, die sich auf diese Sitzung beziehen, entweder verworfen oder totschreiben, basierend auf der Einstellung für den Nachrichtenablauf für die Entität aktiviert. Anders ausgedrückt: Wenn in der Sitzung eine einzelne Nachricht vorhanden ist, die die TTL bestanden hat, sind alle Nachrichten in der Sitzung abgelaufen. Die Nachrichten laufen nur ab, wenn ein aktiver Listener vorhanden ist.

Temporäre Entitäten

Service Bus-Warteschlangen, -Themen und -Abonnements können als temporäre Entitäten erstellt werden, die automatisch entfernt werden, sobald sie für einen angegebenen Zeitraum nicht verwendet wurden.

Die automatische Bereinigung ist in Entwicklungs- und Testszenarien sinnvoll, in denen Entitäten dynamisch erstellt und nach der Nutzung nicht bereinigt werden, da der Test- oder Debuglauf unterbrochen wurde. Sie ist auch nützlich, wenn eine Anwendung dynamische Entitäten erstellt, z. B. eine Antwortwarteschlange, um Antworten wieder in einen Webserverprozess oder in einem anderen relativ kurzlebigen Objekt zu empfangen. In diesem Fall ist es schwierig, diese Entitäten zuverlässig zu bereinigen, wenn die Objektinstanz nicht mehr vorhanden ist.

Die Funktion wird mit der Eigenschaft Automatisches Löschen bei Leerlauf für den Namespace aktiviert. Diese Eigenschaft wird auf die Dauer festgelegt, die eine Entität inaktiv (im Leerlauf) sein muss, bevor sie automatisch gelöscht wird. Der Mindestwert für diese Eigenschaft lautet 5 Minuten.

Wichtig

Das Festlegen der Azure Resource Manager-Sperrebene auf CanNotDelete im Namespace oder auf einer höheren Ebene verhindert nicht, dass Entitäten mit AutoDeleteOnIdle gelöscht werden. Wenn Sie nicht möchten, dass die Entität gelöscht wird, legen Sie die Eigenschaft AutoDeleteOnIdle auf DataTime.MaxValue fest.

Leerlauf

In den folgenden Situationen werden Entitäten als inaktiv (im Leerlauf befindlich) betrachtet:

Entität Was als „im Leerlauf“ betrachtet wird
Warteschlange
  • Keine Sendevorgänge
  • Keine Empfangsvorgänge
  • Keine Aktualisierungen der Warteschlange
  • Keine geplanten Nachrichten
  • Keine Suchvorgänge/Vorschau
Thema
  • Keine Sendevorgänge
  • Keine Aktualisierungen des Themas
  • Keine geplanten Nachrichten
  • Keine Vorgänge für Abonnements des Themas (siehe nächste Zeile)
Subscription
  • Keine Empfangsvorgänge
  • Keine Aktualisierungen des Abonnements
  • Keine Hinzufügung neuer Regeln zum Abonnement
  • Keine Suchvorgänge/Vorschau

Wichtig

Wenn Sie die automatische Weiterleitung für die Warteschlange oder das Abonnement eingerichtet haben, ist dies identisch damit, einen Empfänger Daten in der Warteschlange oder in dem Abonnement empfangen zu lassen, und er ist nicht inaktiv.

SDKs

Nächste Schritte

Weitere Informationen zum Service Bus-Messaging finden Sie in folgenden Artikeln: