Wie mache ich eine automatische Wiederholung der Nachricht, wenn ich Rabbitmq benutze, und setze ttl = 0?

Question

Wir haben ein Szenario wie folgt aus:

Es kann viele Arbeiter sein (a.k.a Verbraucher) in mehreren Knoten, an der mittlerweile Webapp Online-Arbeitsplätze zu dieser Arbeitnehmer vorlegen wird. Wir müssen diese Jobs gleichmäßig verarbeiten und wissen, ob für jeden einzelnen Job Mitarbeiter verfügbar sind. Daher möchten wir Rabbitmq verwenden, um Jobs zu planen und jede Jobmeldung einzustellen, um benachrichtigt zu werden, wenn für jeden Job kein Mitarbeiter vorhanden ist. Aber wir wollen auch, dass Rabbitmq die Job-Umplanung beim Absturz des Workerknotens übernimmt. Wenn ttl jedoch auf 0 gesetzt ist, wird Rabbitmq die Jobnachricht einfach abbrechen, wenn ein Mitarbeiter abstürzt oder ein Netzwerkfehler auftritt.

Ich weiß, wir können DLX verwenden, um tote Nachrichten zu behandeln, aber es ist peinlich, ein Modul zu erstellen, um diese Ausnahmen zu behandeln, da ich hohe Verfügbarkeit für es vornehmen muss. Das wichtigste ist, dass ich nicht unterscheiden kann von Scheduling Scheitern und Scheduling Scheduling, das ist sehr anders zu handhaben!

Habt ihr noch andere Ideen?

Answer 1

RabbitMQ kann nicht explizit wissen, ob es irgendwelche verfügbaren Arbeiter, also Konsumenten, gibt. Es weiß, wie viele Verbraucher die Warteschlange verbrauchen, oder verbunden sind usw. Wenn Sie 5 Arbeiter haben, werden sie in einem Round-Robin-immer-Nachrichten, wie described in the tutorial. Für diesen Teil

Aber auch wir wollen RabbitMQ Auftragsneuplanung wenn Arbeiter Knoten Absturz

einfach nicht auto-ACK verwenden, sondern tun manuellen ACK zu behandeln, sobald der Auftrag abgeschlossen ist (tatsächlich in dem oben genannten Tutorial beschrieben). Wenn die Arbeiter sterben, wird die Nachricht nicht bestätigt und sie wird "erneut in die Warteschlange eingereiht".

Das wichtigste ist, dass ich nicht von der Planung Versagen und Umplanung faiture unterscheiden kann, die sehr unterschiedlich zu handhaben!

Jetzt ist dies ein wenig kompliziert und abhängig von Ihrem Anwendungsfall und/oder wie Sie mit diesen Arten von Fehlern umgehen wollen. Sie könnten einfach nicht ACK, töten den Verbraucher, aber dann, wenn die Nachricht schlecht ist, wird der nächste Verbraucher es bekommen und das gleiche tun und dann wird es für immer weitergehen. Sie könnten diese Nachricht auch weiterleiten (vielleicht fügen Sie einige zusätzliche Informationen hinzu), aber dann ist die Frage, was damit zu tun ist (vielleicht melden Sie es und das ist es?) Usw.