Con el ejemplo y el pseudocódigo que has dado, imaginemos que:
- el
recipient.user1recibe 60 mensajes por minuto - y
perform_task()El método tarda 2 segundos en ejecutarse.
Lo que sucederá aquí es obvio:la latencia entre la llegada de un nuevo mensaje y su procesamiento solo aumentará con el tiempo, alejándose cada vez más del "procesamiento en tiempo real".
system throughput = 30 messages/minute
Para evitar esto, es posible que desee crear un grupo de consumidores para user1 . Aquí podría tener 4 procesos de python distintos ejecutándose en paralelo con los 4 unidos en el mismo grupo para user1 . Ahora, cuando llega un mensaje para user1 uno de los 4 trabajadores lo recogerá y perform_task() .
system throughput = 120 message/minute
En su ejemplo, el message.acknowledge() en realidad no existe, porque su lector de flujo está solo (comandos XREAD).
Si fuera un grupo, el acuse de recibo de los mensajes se vuelve imprescindible, así es como redis sabe que uno de los miembros del grupo sí manejó ese mensaje, por lo que puede "seguir adelante" (puede olvidar que ese mensaje estaba pendiente de acuse de recibo) . Cuando usa grupos, hay un poco de lógica del lado del servidor para garantizar que cada mensaje se entregue a uno de los trabajadores de los grupos de consumidores una vez. (comandos XGROUPREAD). Cuando el cliente ha terminado, emite un reconocimiento de ese mensaje (comandos XACK) para que el "búfer del grupo de consumidores" del lado del servidor pueda eliminarlo y seguir adelante.
Imagínese si un trabajador muriera y nunca reconociera el mensaje. Con un grupo de consumidores, puede estar atento a esta situación (usando los comandos XPENDING) y actuar en consecuencia, por ejemplo, al volver a intentar procesar el mismo mensaje en otro consumidor.
Cuando no está utilizando grupos, el servidor redis no necesita "seguir adelante", el "reconocimiento" se convierte en 100% del lado del cliente/lógica comercial.
