Wie kann ich Haupt- und Failover-MQTT-Abonnenten für eine Jobwarteschlange mit AWS IoT einrichten?

Ich habe ein System, in dem ein Client (nennen wir es ClientA) Anforderungen zu einem bestimmten MQTT-Thema veröffentlichen kann. Der Broker ist, falls es darauf ankommt, Amazon Web Services. Dann habe ich einen anderen Client (nennen wir ihn MainSubscriber), der immer das gleiche Thema abonniert hat, damit er Anforderungen von ClientA abholen und einige Arbeiten ausführen kann, die sich letztendlich in eine Datenbankoperation verwandeln. Die Datenbank ist, falls es darauf ankommt, DynamoDB.

Da der MainSubscriber möglicherweise nicht immer erreichbar / online ist, besteht der Wunsch, dass ein Failover-Abonnent die Failover-Sicherung des Hauptteilnehmers ist. Die Idee ist, dass, wenn der Hauptteilnehmer die Anforderung nicht rechtzeitig bearbeitet, der Failover-Teilnehmer einschalten und die entsprechende Arbeits- / Datenbankoperation ausführen würde. Die Herausforderung besteht darin, dass die "Arbeit" und die daraus resultierende "Datenbankoperation" nicht sowohl von Haupt- als auch von Failover-Abonnenten dupliziert werden dürfen.

Hier ist eine logische Systemarchitekturzeichnung für dieses System.

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

Natürlich gibt es bei einem solchen System einige Herausforderungen:

1. Wie zeigt der Hauptteilnehmer dem Failover-Teilnehmer an, dass er an der Anforderung arbeitet?
2. Wie erkennt der Failover-Abonnent, dass der Hauptteilnehmer die Anforderung nicht angenommen hat und mit der Arbeit beginnen muss?
3. Wie hält der Failover-Abonnent dann den Hauptteilnehmer zurück, falls er plötzlich wieder online geht und die Anfrage entgegennimmt?
4. Wie gehe ich mit Synchronitätsproblemen zwischen Haupt- und Failover-Abonnenten um?

Ich würde das Rad lieber nicht neu erfinden müssen, wenn es für ein solches Schema bereits eine bestehende Lösung gibt. Meine erste Frage ist also, ob es da draußen schon etwas gibt.

Wenn nicht, habe ich darüber nachgedacht, DynamoDB mit stark konsistenten Lesevorgängen als Vermittler zwischen dem Haupt- und dem Failover-Abonnenten zu verwenden. Meine zweite Frage ist also, ob es dafür gut etablierte Systeme gibt.

Laut AWS SQS-Dokumentation (wie Sie sagten, der Broker ist AWS) sollte dies nativ sein:

Unmittelbar nach dem Empfang der Nachricht verbleibt sie in der Warteschlange. Um zu verhindern, dass andere Verbraucher die Nachricht erneut verarbeiten, legt Amazon SQS ein Sichtbarkeitszeitlimit fest. In diesem Zeitraum verhindert Amazon SQS, dass andere konsumierende Komponenten die Nachricht empfangen und verarbeiten.

Das Problem besteht darin, das richtige Sichtbarkeitszeitlimit entsprechend Ihrer maximalen Verarbeitungszeit zu finden.

Sie haben immer noch eine geringe Chance, dass beide Abonnenten dieselbe Nachricht verarbeiten. In diesem Fall sollte Ihr Abonnentencode versuchen, eine idempotente Ausgabe für die Datenbank zu erstellen (mindestens derselbe Primärschlüssel) und einen Fehler beim Versuch, denselben Datensatz einzufügen, ordnungsgemäß behandeln.

Vielleicht möchten Sie sich das Konzept der Dead-Letter-Warteschlangen von AWS SQS ansehen . Aus den AWS-Dokumenten:

Eine Warteschlange für tote Buchstaben ist eine Warteschlange, auf die andere (Quell-) Warteschlangen für Nachrichten abzielen können, die nicht erfolgreich verarbeitet (verbraucht) werden können. Sie können diese Nachrichten in der Warteschlange für nicht zustellbare Nachrichten beiseite legen und isolieren, um festzustellen, warum ihre Verarbeitung nicht erfolgreich war.

Wenn Sie also den Hauptteilnehmer zum Abhören aus der normalen Warteschlange und den sekundären Teilnehmer zum Abhören aus der Warteschlange für nicht zustellbare Nachrichten anweisen, sollte das Failover-Problem behoben sein.

Damit sind auch 1, 2 und 3 Ihrer Probleme behoben. In diesem Fall müssen der Haupt- und der Sekundärteilnehmer nicht miteinander sprechen.

Außerdem baut auf Tensibai Antwort, stellen Sie sicher , dass Ihre Teilnehmer - Code geschrieben ist , um eine Nachricht zu einem Zeitpunkt zu erhalten , wenn mehrere Teilnehmer die gleiche Warteschlange hören aufgrund dervisibility timeout

Nachteil wäre, dass es zu einer Verzögerung bei der Verarbeitung kommen würde, Nachrichten erst nach einer Weile in die Warteschlange für tote Briefe gelangen.

Falls Sie das nicht möchten, können Sie mit Tensibais Antwort fortfahren. Und wenn Sie das tolerieren können, anstatt eine zusätzliche Dynamo-Tabelle für Statusprüfungen zu haben, können Sie diese verwenden.