Ist RabbitMQ, ZeroMQ, Service Broker oder etwas Ähnliches eine geeignete Lösung für die Erstellung eines Hochverfügbarkeitsdatenbank-Webservice?

Question

Ich habe einen CRUD-Webservice und bin damit beauftragt worden, einen Weg zu finden, um sicherzustellen, dass wir keine Daten verlieren, wenn die Datenbank ausfällt. Jeder ist sich bewusst, dass wir, wenn die Datenbank ausfällt, nicht "lesen" können, aber für eine bestimmte Teilmenge der Operationen wollen wir sicherstellen, dass wir keine Daten verlieren.

Ich habe den Eindruck, dass dies von Diensten wie 0MQ, RabbitMQ oder einem der Microsoft MQ-Dienste abgedeckt ist. Obwohl ich nach ein paar Tagen Lesen und Nachforschung nicht einmal sicher bin, dass es sich bei den Nachrichten, über die wir in MQ-Services sprechen, um Datenbankoperationen handelt. Ich bin mir jedoch 100% sicher, dass ich so viele Hallo Welten anstellen kann, wie ich mir jemals erhoffen kann.

Wenn ich eine Nachrichtenwarteschlange verwenden kann, um der Datenbank eine Schutzebene hinzuzufügen, würde ich mich zu Rabbit neigen (weil es anscheinend durch Abstürze bestehen bleibt), aber das Ziel ist eine Microsoft SQL Server Datenbank, vielleicht eine von Ihre Lösungen (wie SQL Service Broker oder MSMQ) sind besser geeignet.

Die wirklich grundlegende Frage, über die ich mir noch nicht sicher bin, ist, ob ich überhaupt mit dem richtigen Kartenspiel spiele (sozusagen).

Mit dem Wunsch nach einem hochverfügbarem Webservice, der auch bei einem Ausfall der Datenbank funktioniert, ist es sinnvoll, eine Rabbit MQ Instanz "zwischen" Webservice und Datenbank zu stellen? Vielleicht ist der richtige Link in der Kette, dass RabbitMQ Nachrichten an den Webserver sendet?

Oder gibt es eine andere Lösung, um dies zu erreichen? Im Moment gibt es eine Reihe von Ideen, um einen Weg zu finden, Weblogs im Falle eines Datenbankausfalls oder so etwas zu erstellen ... aber wir sind immer noch in einem frühen Stadium, dass (zumindest ich) keine Ahnung habe, was ich 'weiß'. Ich werde es tun.

Ist Nachrichtenwarteschlange die richtige Lösung?

Answer 1

Die Einführung einer Nachrichtenwarteschlange zwischen einem Dienst und einer Datenbank ist sicherlich eine Möglichkeit, die Dienstverfügbarkeit zu verbessern. Das Schreiben in eine lokale Warteschlange ist immer billiger und verfügbarer als das Schreiben in eine Datenbank.

Durch die Verwendung von Warteschlangen erhalten Sie außerdem die Kontrolle über den Umfang des Datenbankverkehrs, den Ihre Datenbank zu Spitzenzeiten bewältigen muss.

Um dies zu tun, müssen Sie jedoch beachten, dass die Anforderung beim Schreiben einer Datenbank in die Warteschlange gestellt wird und offline geliefert und verarbeitet wird.

Selbst unter Bedingungen, bei denen dies fast augenblicklich geschieht, verlieren Sie den Vorteil, den die synchrone Art Ihres aktuellen Dienstes Ihnen ermöglicht. Und dieser Vorteil ist, dass Ihre Service-Kunden (oder Web-Clients) immer wissen können, ob der Vorgang erfolgreich war oder nicht.

Ich habe über dieses Thema vor here geschrieben. Der Benutzer, der die Frage gepostet hat, hatte ähnliche Bedenken. Ob Sie dies tun oder nicht, ist eine Entscheidung, die Sie treffen müssen.

Für die Technologie-Stacks, an die Sie denken, 0MQ ist nicht wirklich ein Nachrichtenwarteschlangensystem, es ist mehr wie Sockets auf Steroiden.

Von den anderen MQ-Plattformen, die Sie erwähnen, unterstützen alle die Haltbarkeit durch Systemabstürze. MSMQ ist eine viel leichtere Lösung als rabbitMQ (die das AMQP-Protokoll implementiert und so Messaging-Muster out-of-the-box unterstützt).

Der Servicebroker ist eine Datenbanktechnologie und lässt sich nicht gut mit Code integrieren, mit Ausnahme von SqlDependency oder etwas namens Notifications, das auf der StreamInsight-Plattform aktiviert ist.

Ich würde für MSMQ gehen (die haltende Nachrichtenübermittlung über Transaktionswarteschlangen unterstützt), da es leichtgewichtig ist, Teil von Windows, und Core.NET-Bibliothek unterstützt.