Met het voorbeeld en de pseudo-code die je hebt gegeven, laten we ons voorstellen dat:
- de
recipient.user1krijgt 60 berichten per minuut - en de
perform_task()methode duurt 2 seconden om uit te voeren.
Wat hier zal gebeuren is duidelijk:de latentie tussen het binnenkomen van een nieuw bericht en de verwerking ervan zal in de loop van de tijd alleen maar toenemen en steeds verder afdrijven van "realtime verwerking".
system throughput = 30 messages/minute
Om dit te omzeilen, kunt u een consumentengroep maken voor user1 . Hier kunt u 4 verschillende python-processen parallel laten lopen met alle 4 in dezelfde groep voor user1 . Als er nu een bericht binnenkomt voor user1 een van de 4 werkers pakt het op en perform_task() .
system throughput = 120 message/minute
In uw voorbeeld is de message.acknowledge() bestaat niet echt, omdat je streamlezer alleen is (XREAD-commando's).
Als het een groep was, wordt de bevestiging van berichten essentieel, zo weet Redis dat een van de groepsleden dat bericht inderdaad heeft afgehandeld, dus het kan "verder gaan" (het kan het feit vergeten dat dat bericht in afwachting was van bevestiging) . Wanneer u groepen gebruikt, is er een beetje logica aan de serverzijde om ervoor te zorgen dat elk bericht eenmaal wordt afgeleverd bij een van de werknemers van de consumentengroepen (XGROUPREAD-opdrachten). Wanneer de client klaar is, geeft hij een bevestiging van dat bericht (XACK-commando's) zodat de "consumentengroepbuffer" aan de serverzijde het kan verwijderen en verder kan gaan.
Stel je voor dat een werknemer stierf en de boodschap nooit zou bevestigen. Met een consumentengroep kun je op deze situatie letten (met behulp van XPENDING-commando's) en ernaar handelen door bijvoorbeeld opnieuw te proberen hetzelfde bericht bij een andere consument te verwerken.
Als u geen groepen gebruikt, hoeft de redis-server niet "door te gaan", de "bevestiging" wordt 100% client-side/bedrijfslogica.