Con l'esempio e lo pseudo codice che hai fornito, immaginiamo che:
- il
recipient.user1riceve 60 messaggi al minuto - e
perform_task()il metodo richiede 2 secondi per essere eseguito.
Quello che accadrà qui è ovvio:la latenza tra l'arrivo di un nuovo messaggio e la sua elaborazione non farà che aumentare nel tempo, allontanandosi sempre più dall'"elaborazione in tempo reale".
system throughput = 30 messages/minute
Per aggirare questo problema, potresti voler creare un gruppo di consumatori per user1 . Qui potresti avere 4 distinti processi Python in esecuzione in parallelo con tutti e 4 uniti nello stesso gruppo per user1 . Ora quando arriva un messaggio per user1 uno dei 4 lavoratori lo raccoglierà e perform_task() .
system throughput = 120 message/minute
Nel tuo esempio, il message.acknowledge() in realtà non esiste, perché il tuo lettore di stream è solo (comandi XREAD).
Se fosse un gruppo, il riconoscimento dei messaggi diventa essenziale, è così che redis sa che uno dei membri del gruppo ha effettivamente gestito quel messaggio, quindi potrebbe "andare avanti" (potrebbe dimenticare il fatto che quel messaggio era in attesa di riconoscimento) . Quando si utilizzano i gruppi, è presente un po' di logica lato server per garantire che ogni messaggio venga recapitato a uno dei lavoratori dei gruppi di consumatori una volta (comandi XGROUPREAD). Quando il client ha terminato, emette un riconoscimento di quel messaggio (comandi XACK) in modo che il "buffer del gruppo di consumatori" lato server possa eliminarlo e andare avanti.
Immagina se un lavoratore morisse e non riconoscesse mai il messaggio. Con un gruppo di consumatori, puoi fare attenzione a questa situazione (usando i comandi XPENDING) e agire su di essa, ad esempio riprovando a elaborare lo stesso messaggio in un altro consumatore.
Quando non stai utilizzando i gruppi, il server redis non ha bisogno di "andare avanti", il "riconoscimento" diventa 100% lato client/logica aziendale.
