Stellen wir uns mit dem Beispiel und dem Pseudo-Code Folgendes vor:
- der
recipient.user1erhält 60 Nachrichten pro Minute - und die
perform_task()Die Ausführung der Methode dauert 2 Sekunden.
Was hier passieren wird, liegt auf der Hand:Die Latenz zwischen dem Eingang einer neuen Nachricht und deren Verarbeitung wird mit der Zeit immer größer und entfernt sich immer weiter von der „Echtzeitverarbeitung“.
system throughput = 30 messages/minute
Um dies zu umgehen, können Sie eine Consumer-Gruppe für user1 erstellen . Hier könnten Sie 4 verschiedene Python-Prozesse parallel laufen lassen, wobei alle 4 in derselben Gruppe für user1 sind . Wenn jetzt eine Nachricht für user1 eingeht Einer der 4 Arbeiter wird es abholen und perform_task() ausführen .
system throughput = 120 message/minute
In Ihrem Beispiel die message.acknowledge() existiert eigentlich nicht, weil Ihr Stream-Reader allein ist (XREAD-Befehle).
Wenn es sich um eine Gruppe handelt, wird die Bestätigung von Nachrichten unerlässlich. So weiß Redis, dass eines der Gruppenmitglieder diese Nachricht tatsächlich bearbeitet hat, sodass es "weitermachen" kann (es kann die Tatsache vergessen, dass diese Nachricht noch nicht bestätigt wurde). . Wenn Sie Gruppen verwenden, gibt es ein wenig serverseitige Logik, um sicherzustellen, dass jede Nachricht einmal an einen der Worker der Verbrauchergruppe zugestellt wird (XGROUPREAD-Befehle). Wenn der Client fertig ist, gibt er eine Bestätigung dieser Nachricht (XACK-Befehle) aus, so dass der serverseitige "Verbrauchergruppenpuffer" sie löschen und fortfahren kann.
Stellen Sie sich vor, ein Arbeiter starb und hätte die Nachricht nie zur Kenntnis genommen. Mit einer Verbrauchergruppe können Sie auf diese Situation achten (mit XPENDING-Befehlen) und darauf reagieren, indem Sie beispielsweise erneut versuchen, dieselbe Nachricht in einem anderen Verbraucher zu verarbeiten.
Wenn Sie keine Gruppen verwenden, muss der Redis-Server nicht "weitermachen", die "Bestätigung" wird zu 100 % zur clientseitigen/Geschäftslogik.
