Empfehlungen zum Organisieren von Warteschlangen in Service Broker

Ich habe eine Service Broker-Anwendung, die derzeit 5 oder 6 Warteschlangen auf zwei Servern hat.

Der allgemeine Workflow lautet:

Server A.

• Der Benutzer füllt einige Tabellen
• Der Benutzer löst einen gespeicherten Prozess aus, der eine Nachricht in eine Header-Warteschlange stellt, die angibt, dass noch Arbeit zu erledigen ist
• Der Broker liest aus dieser Header-Warteschlange und erstellt eine möglicherweise große Anzahl von Nachrichten, die an Server B gesendet werden sollen

Server B.

• Alle Nachrichten werden in eine Warteschlange gestellt
• In dieser Warteschlange wird die Nachricht untersucht und entbündelt, die Nutzdaten werden ausgeführt und eine Antwort wird von einem anderen Satz von Prozessen / Tabellen gesammelt, mit denen wir interagieren
• Die Antwortnachricht wird erstellt und an Server A zurückgesendet

Server A.

• Antwortnachrichten werden in eine spezielle Warteschlange gestellt und zum Aktualisieren von Tabellen verwendet, die der Benutzer oben ausgefüllt hat
• Enddialognachrichten werden aus der Initiatorwarteschlange gelesen und zum Aktualisieren einer anderen Tabelle verwendet, die den Fortschritt eines Headerdatensatzes verfolgt (dh 50 von 100 verarbeiteten Nachrichten).
• Wenn wir feststellen, dass der Header-Datensatz vollständig verarbeitet wurde, wird eine neue Nachricht an eine andere Warteschlange gesendet, die eine Benachrichtigungs-E-Mail sendet

Ich hatte die Empfehlung, einige dieser Warteschlangen auf Server A zu konsolidieren, und bin mir nicht sicher, welche Vorgehensweise hierfür am besten geeignet ist. Zwei der Warteschlangen haben ein relativ hohes Volumen an Nachrichtenverarbeitung, und die E-Mail-Warteschlange ist ziemlich langsam.

Wir haben (glaube ich) gute Arbeit bei der Verwaltung von Nachrichtentypen geleistet, sodass wir theoretisch alles in eine Warteschlange stellen konnten und die Anwendung weiterhin funktionieren würde.

Gibt es eine bewährte Methode, wann separate Warteschlangen verwaltet und wann in einem solchen Szenario konsolidiert werden müssen?

Dies ist eine offene Frage ohne klare Wahl. YMMV also musst du testen. Hier ist meine Meinung:

Eine Warteschlange für alles zu haben, ist eine gute Wahl, wenn Sie die Anzahl der aktivierten Aufgaben steuern möchten, da es keine globalen max_queue_readers gibt. Davon abgesehen sehe ich nicht viele Vorteile. Man könnte argumentieren, dass ein einzelner aktivierter Prozess einfacher zu warten ist, aber ich denke, Sie sollten beim Erstellen eines SSB-aktivierten Prozesses eine Art Vorlagen- / Codegenerierung verwenden, da in der Regel viel Cookie-Cutter-Code und wenig spezifisch für die Servicegeschäftslogik ist.

Ich kann jedoch mehrere potenzielle Probleme mit einer einzelnen Warteschlange erkennen, und es handelt sich um alle Arten von Problemen, die sich nur dann manifestieren, wenn die Dinge bereits schlecht laufen (dh unter Stress / Last):

• Latenz und Verarbeitungsserialisierung. Mit nur einer Warteschlange ist es möglich, die max_queue_readers auf max zu plateauieren und Nachrichten, die wenig Verarbeitung erfordern, in der Warteschlange zu haben, die darauf warten, dass sie an die Reihe kommen. Durch separate Warteschlangen können Dienste mit geringer Latenz ihre Warteschlangen schnell entleeren, während Warteschlangen mit hoher Last in ihrem eigenen (langsameren) Tempo ablaufen.
• Ein Anstieg der Nachrichten für einen Dienst wirkt sich auf alle Dienste aus. Wie oben, jedoch für Spikes. Ein Speicherauszug mit einer hohen Anzahl von Nachrichten (z. B. ein Handbuch "oop wir müssen diese 1-MM-Elemente erneut verarbeiten") führt dazu, dass alle anderen Dienste in derselben Warteschlange warten, bis die Spitze leer ist, bevor sie Zugriff auf ihre Nachrichten erhalten (is etwas komplexer aufgrund der Sperre von Konversationsgruppen, aber letztendlich ist die Verarbeitung FIFO).
• vermeidbare Besuche im hässlichen Land der großen Warteschlangen . Wenn bei Ihrem RAM / IO / CPU / Aktivierungscode bei N Nachrichten Probleme mit großen Warteschlangen auftreten, erreicht eine Warteschlange für alle Dienste N schneller / häufiger als eine Warteschlange pro Dienst.

Im Allgemeinen empfehle ich eine Warteschlange für jeden Dienst.