Vorabruf von Azure Service Bus-Nachrichten
Das Prefetch-Feature ruft Nachrichten im Hintergrund in einen lokalen Prefetch-Puffer ab, bis die Prefetch-Anzahl erreicht ist. Nachrichten werden aus dem Puffer bereitgestellt. Währenddessen wird Speicherplatz im Puffer freigegeben, und der Empfänger kann mit Prefetch weitere Nachrichten im Hintergrund vorab abrufen.
Legen Sie zum Aktivieren des Vorabruffeatures die Vorabrufanzahl des Warteschlangen- oder Abonnementclients auf eine Zahl größer als null fest. Durch Festlegen des Werts auf 0 (null) wird der Vorabruf deaktiviert. Wenn sich Nachrichten im Vorabrufpuffer befinden, nachdem das Feature deaktiviert wurde, empfängt die Anwendung zuerst diese im Puffer befindlichen Nachrichten und wechselt dann zum Dienst.
Legen Sie die Eigenschaft „Anzahl der Vorabrufe“ für die Objekte ServiceBusReceiverOptions und ServiceBusProcessorOptions fest.
Hinweis
Das Java Script SDK unterstützt das Vorabruffeature nicht.
Solange Nachrichten im Vorabrufpuffer vorhanden sind, werden alle nachfolgenden Empfangsaufrufe sofort aus dem Puffer erfüllt. Der Puffer wird im Hintergrund aufgefüllt, wenn Speicherplatz verfügbar wird. Wenn keine zu übermittelnden Nachrichten vorhanden sind, leert der Empfangsvorgang den Puffer und wartet oder sperrt dann wie erwartet.
Warum ist Vorabruf nicht die Standardoption?
Vorabruf beschleunigt den Nachrichtenfluss, indem eine Nachricht zum lokalen Abruf bereitgehalten wird, bevor die Anwendung sie anfragt. Diese Durchsatzbeschleunigung ist das Ergebnis eines Kompromisses, die der Anwendungsautor explizit treffen muss:
Wenn Sie den Modus Empfangen und Löschen verwenden, sind jegliche Nachrichten, die in den Vorabrufpuffer abgerufen werden, nicht mehr in der Warteschlange verfügbar. Die Nachrichten verbleiben nur im Arbeitsspeicher-Vorabrufpuffer, bis sie in der Anwendung empfangen werden. Wenn die Anwendung vor dem Eingang der Nachrichten in der Anwendung beendet wird, gehen diese Nachrichten unwiederbringlich verloren.
Wenn Sie den Empfangsmodus Peek-Lock verwenden, gelangen Nachrichten, die in den Vorabrufpuffer abgerufen wurden, im gesperrten Zustand in den Puffer. Der Sperrenzeitgeber startet in dem Moment, in dem die Nachricht mit Prefetch in den Puffer eingefügt wird. Wenn der Vorabrufpuffer groß ist und die Verarbeitung so lange dauert, dass Sperren für Nachrichten ablaufen, während sie sich im Vorabrufpuffer befinden oder sogar während die Anwendung die Nachricht verarbeitet, kann es einige verwirrende Ereignisse geben, die von der Anwendung behandelt werden müssen. Die Anwendung kann eine Nachricht mit einer abgelaufenen oder in Kürze ablaufenden Sperre empfangen. Wenn dies der Fall ist, verarbeitet die Anwendung möglicherweise die Nachricht, stellt dann aber fest, dass sie die Nachricht aufgrund einer abgelaufenen Sperre nicht abschließen kann. Die Anwendung kann die LockedUntilUtc-Eigenschaft überprüfen. Bedenken Sie jedoch, dass eine Taktverschiebung zwischen dem Broker und der Uhr des lokalen Computers vorliegt.
Wenn die Sperre im Vorabrufpuffer automatisch abläuft, wird die Nachricht als abgebrochen behandelt und wieder für den Abruf aus der Warteschlange zur Verfügung gestellt. Dann wird die Nachricht erneut in den Vorabrufpuffer abgerufen und an dessen Ende platziert. Wenn der Vorabrufpuffer während des Nachrichtenablaufs in der Regel nicht abgearbeitet werden kann, werden Nachrichten zwar wiederholt vorab abgerufen, aber nie effektiv in einen nutzbaren (gültig gesperrten) Zustand versetzt. Sie werden schließlich in die Warteschlange für unzustellbare Nachrichten verschoben, sobald die maximale Anzahl der Zustellungen überschritten ist.
Wenn eine Anwendung eine Nachricht explizit abbricht, kann die Nachricht wieder für den Abruf aus der Warteschlange verfügbar sein. Wenn der Vorabruf aktiviert ist, wird die Nachricht erneut in den Vorabrufpuffer abgerufen und an dessen Ende platziert. Da Nachrichten in der FIFO-Reihenfolge (First-In, First Out) aus dem Vorabrufpuffer geleert werden, kann die Anwendung Nachrichten möglicherweise in einer anderen Reihenfolge empfangen. Beispielsweise kann die Anwendung eine Nachricht mit der ID 2 und dann eine Nachricht mit der ID 1 (die zuvor abgebrochen wurde) aus dem Puffer empfangen.
Wenn Sie für die Nachrichtenverarbeitung ein hohes Maß an Zuverlässigkeit benötigen und die Verarbeitung viel Arbeit und Zeit in Anspruch nimmt, empfiehlt es sich, die Vorabruffunktion dosiert oder gar nicht zu verwenden. Wenn Sie hohe Durchsatzraten benötigen und die Nachrichtenverarbeitung im Allgemeinen günstig ist, bietet der Vorabruf erhebliche Durchsatzvorteile.
Die maximale Anzahl der Vorabrufvorgänge und die für die Warteschlange oder das Abonnement konfigurierte Sperrdauer müssen so abgestimmt werden, dass das Zeitlimit für die Sperre mindestens die kumulative erwartete Verarbeitungszeit der erwarteten Nachrichten für die maximale Größe des Vorabrufpuffers plus eine Nachricht überschreitet. Gleichzeitig sollte die Sperrdauer nicht so lang sein, dass Nachrichten während der Sperrung ihre maximale Gültigkeitsdauer überschreiten können, da dies bedeuten würde, dass sie entfernt werden, wenn sie beim Vorabruf nicht abgeschlossen werden konnten.
Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.
Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.