Com o exemplo e pseudocódigo que você deu, vamos imaginar que:

• o recipient.user1 está recebendo 60 mensagens por minuto
• e o perform_task() O método leva 2 segundos para ser executado.

O que acontecerá aqui é óbvio:a latência entre a chegada de uma nova mensagem e seu processamento só aumentará com o tempo, afastando-se cada vez mais do "processamento em tempo real".

system throughput = 30 messages/minute

Para contornar isso, você pode criar um grupo de consumidores para user1 . Aqui você pode ter 4 processos python distintos sendo executados em paralelo com todos os 4 unidos no mesmo grupo para user1 . Agora, quando uma mensagem chega para user1 um dos 4 trabalhadores irá pegá-lo e perform_task() .

system throughput = 120 message/minute

No seu exemplo, o message.acknowledge() na verdade não existe, porque seu leitor de fluxo está sozinho (comandos XREAD).

Se fosse um grupo, o reconhecimento das mensagens torna-se essencial, é assim que o redis sabe que um dos membros do grupo de fato lidou com essa mensagem, para que possa "seguir em frente" (pode esquecer o fato de que essa mensagem estava pendente de reconhecimento) . Quando você está usando grupos, há um pouco de lógica do lado do servidor para garantir que cada mensagem seja entregue a um dos trabalhadores dos grupos de consumidores uma vez (comandos XGROUPREAD). Quando o cliente termina, ele emite uma confirmação dessa mensagem (comandos XACK) para que o "buffer do grupo de consumidores" do lado do servidor possa excluí-la e seguir em frente.

Imagine se um trabalhador morresse e nunca reconhecesse a mensagem. Com um grupo de consumidores, você pode observar essa situação (usando comandos XPENDING) e agir sobre ela, por exemplo, tentando novamente processar a mesma mensagem em outro consumidor.

Quando você não está usando grupos, o servidor redis não precisa "seguir em frente", o "reconhecimento" se torna 100% do lado do cliente/lógica de negócios.