Grundsätzlich sind meine Konsumenten auch Produzenten. Wir erhalten einen ersten Datensatz und dieser wird in die Warteschlange gesendet. Ein Konsument nimmt einen Gegenstand und verarbeitet ihn, von diesem Punkt gibt es 3 Möglichkeiten:
Mein Problem ist mit Schritt 3, da die Warteschlange zuerst sehr schnell wächst, ist es möglich, dass ein Teil der Daten in einen Teil zerlegt wird, der in der Warteschlange dupliziert wird und die Verbraucher ihn weiter verarbeiten und in einer Endlosschleife enden .
Ich denke, der Weg, dies zu verhindern, besteht darin, zu verhindern, dass Duplikate in die Warteschlange gelangen. Ich kann das auf der Client-Seite nicht tun, weil ich im Laufe einer Stunde viele Kerne habe, die mit Milliarden von Datenpunkten umgehen (damit jeder Client es scannt, bevor es mich abschickt, würde es mich zu sehr verlangsamen). Ich denke, das muss auf der Serverseite getan werden, aber, wie ich bereits erwähnte, die Daten sind ziemlich groß und ich weiß nicht, wie man effizient keine Duplikate sicherstellen kann.
Ich könnte das Unmögliche verlangen, dachte aber, ich würde es versuchen. Irgendwelche Ideen würden sehr geschätzt werden.Das Kernproblem scheint das zu sein:
%Vor%Sie können sich auf die Eindeutigkeit Ihrer eingereihten Elemente konzentrieren, ganz wie Sie wollen, aber das obige Problem ist, wo Sie Ihre Bemühungen konzentrieren sollten, IMO. Eine Möglichkeit, Endlosschleifen zu verhindern, besteht möglicherweise darin, ein "besuchtes" Bit in Ihrer Nachrichtennutzlast zu haben, das von den Benutzern festgelegt wird, bevor sie das defekte Element erneut in die Warteschlange stellen.
Eine andere Option wäre, die Verbraucher in eine spezielle Warteschlange zurückzustellen, die etwas anders behandelt wird, um eine Endlosschleife zu verhindern. In jedem Fall sollten Sie das Problem angehen, indem Sie es als Kernelement der Strategie Ihrer Anwendung behandeln, anstatt eine Funktion eines Messaging-Systems zu verwenden, um es zu umgehen.
Ich denke, selbst wenn Sie das Problem beheben könnten, keine Duplikate in die Warteschlange zu senden, werden Sie dieses Problem früher oder später haben:
Aus der RabbitMQ-Dokumentation: "Wiederherstellung nach Fehler: Wenn ein Client aufgrund eines Fehlers des Knotens, mit dem der Client verbunden war, vom Broker getrennt wurde, ist es für den Broker möglich, wenn der Client ein Veröffentlichungsclient war Nachrichten vom Client akzeptiert und weiter gegeben haben, ohne dass der Client eine Bestätigung für sie erhalten hat, und ebenso auf der konsumierenden Seite ist es möglich, dass der Client Bestätigungen für Nachrichten ausgegeben hat und keine Ahnung hat, ob diese Bestätigungen es dem Broker und nicht gegeben haben wurden verarbeitet, bevor der Fehler aufgetreten ist.Kurz gesagt, müssen Sie noch sicherstellen, dass Ihre konsumierenden Clients doppelte Nachrichten identifizieren und damit umgehen können. "
Im Prinzip sieht das so aus: Sie senden eine Anfrage an rabbitmq, rabbitmq antwortet mit einem ACK, aber aus irgendeinem Grund erhält Ihr Verbraucher oder Produzent dieses ACK nicht. Rabbitmq hat keine Möglichkeit zu wissen, dass die Bestätigung nicht empfangen wurde, und Ihr Produzent wird die Nachricht erneut senden, ohne jemals eine Bestätigung erhalten zu haben.
Es ist ein Problem, doppelte Nachrichten zu verarbeiten, insbesondere in Apps, in denen Messaging als eine Art von RPC verwendet wird, aber es sieht so aus, als ob dies bei dieser Art von Messaging-Architektur unvermeidlich ist.