Das Bearbeiten von Anforderungen auf diese Weise offline ist ein häufiges Muster, wenn Sie mit einer großen Anzahl von Anfragen arbeiten.

Ob Sie dies tun sollten oder können, hängt von einer Reihe von Faktoren ab.

Der Hauptfaktor ist: Müssen Ihre Anrufer die Antwort auf ihre Anfragen synchron sehen?

Was ich meine ist, muss der Anrufer sofort und mit absoluter Sicherheit wissen, ob die Datenbank ihre Daten erfolgreich als Teil der Anrufantwort übergeben hat? Wenn dies der Fall ist, ist es nicht wirklich eine Option, die Anfrage offline zu bearbeiten.

Wenn es jedoch akzeptabel ist, dass Anrufern eine Antwort gesendet werden kann, die besagt, dass ihre Anfrage offline verarbeitet wird (und jede erforderliche Antwort auch offline gesendet wird), wird die Verwendung einer Warteschlange definitiv der Gesamtarchitektur zugute kommen.

Das erste, was davon profitieren wird, sind Probleme bei der Verfügbarkeit von Front-End-Systemen.

Wenn Sie Tausende von Anfragen über einen kurzen Zeitraum bearbeiten und jede Anfrage von einem Thread bearbeitet wird, der dann verschwindet und Daten in eine Datenbank einfügt, werden Sie höchstwahrscheinlich auf das Problem stoßen, wo kein verfügbarer Dispatcher-Thread existiert eingehende Anfragen

Durch die Reduzierung der Back-End-Arbeit, die IIS ausführt (das Schreiben in eine lokale Warteschlange ist im Vergleich zu einem Datenbankaufruf jedoch relativ günstig), verringern Sie die Wahrscheinlichkeit eines Verfügbarkeitsfehlers.

Zweitens können Sie mithilfe einer Warteschlange den Back-End-Datenverkehr drosseln, da Sie den Durchsatz bei der Back-End-Verarbeitung kontrollieren können.

Sie könnten beispielsweise einen Warteschlangenleseprozess mit einem einzigen Thread haben, der eine Anfrage aus der Warteschlange nimmt und sie in eine Datenbank verarbeitet. Wenn Sie feststellen, dass sich Nachrichten in der Warteschlange befinden, können Sie den Warteschlangenleserdienst einfach durch Bereitstellen weiterer Instanzen erweitern.

Dies bedeutet, dass Sie die Wahrscheinlichkeit von Datenbankkonfliktproblemen reduzieren, da Sie die Anzahl der auf die Datenbank zugreifenden Threads zu einem bestimmten Zeitpunkt besser kontrollieren können.

Durch die Verwendung von Warteschlangen treten also weniger Fehler auf, und Sie haben einen geringeren Verwaltungsaufwand, der für gut geschriebene Anwendungen kennzeichnend ist. Dies insbesondere, wenn Sie in Betracht ziehen, Ihre Datenbank auf Ihrem Webserver zu hosten!

Sie sollten auch ein Architekturmuster mit dem Namen CQRS lesen, von dem eines der zentralen Prinzipien ist um Ihre Datenbank offline zu schreiben.

Eine asynchrone Architektur hat viele Vorteile (wie von Hugh identifiziert), hat aber definitiv größere Kosten und Komplexität. Dies sollte sorgfältig abgewogen werden. Aus 2 Komponenten (Web-App und DB) müssen Sie nun 4 Komponenten (Web-App, DB, Batch-Service, MSMQ) entwickeln, warten und überwachen. Sie haben gesagt, dass der Webserver und der DB-Server dieselbe Maschine ist, was bei Ihren Leistungsanforderungen seltsam ist. Morgen müssen Sie möglicherweise die Web-App, Batch-Service und DB 3 separate Maschinen hosten. Jetzt beinhaltet MSMQ auch das Netzwerk. Eine weitere Sache, die schief gehen kann. Multithread Batch-Prozessor ist auch nicht einfach, was, wenn Sie jede Nachricht in der Reihenfolge verarbeiten müssen, die sie generiert wurden (zumindest für eine bestimmte Entität) Logik kann komplex werden.

Wenn möglich, beide Lösungen messen und entscheiden.