S příkladem a pseudokódem, který jste uvedli, si představme, že:
recipient.user1dostává 60 zpráv za minutu- a
perform_task()provedení metody trvá 2 sekundy.
Co se zde stane, je zřejmé:latence mezi příchodem nové zprávy a jejím zpracováním bude časem jen růst a bude se stále více vzdalovat od „zpracování v reálném čase“.
system throughput = 30 messages/minute
Chcete-li to obejít, možná budete chtít vytvořit skupinu spotřebitelů pro user1 . Zde byste mohli mít 4 různé procesy python spuštěné paralelně se všemi 4 spojenými ve stejné skupině pro user1 . Nyní, když přijde zpráva pro user1 jeden ze 4 pracovníků jej vyzvedne a perform_task() .
system throughput = 120 message/minute
Ve vašem příkladu message.acknowledge() ve skutečnosti neexistuje, protože vaše čtečka streamů je sama (příkazy XREAD).
Pokud by se jednalo o skupinu, potvrzení zpráv se stává nezbytným, takže redis ví, že jeden z členů skupiny ve skutečnosti tuto zprávu zpracoval, takže se může „posunout“ (může zapomenout na skutečnost, že tato zpráva čekala na potvrzení) . Když používáte skupiny, existuje určitá logika na straně serveru, která zajišťuje, že každá zpráva bude doručena jednomu z pracovníků spotřebitelské skupiny jednou (příkazy XGROUPREAD). Když klient skončí, vydá potvrzení o této zprávě (příkazy XACK), aby ji "vyrovnávací paměť skupiny spotřebitelů" na straně serveru mohla smazat a pokračovat.
Představte si, že by pracovník zemřel a zprávu nikdy nepotvrdil. Se skupinou spotřebitelů si můžete na tuto situaci dávat pozor (pomocí příkazů XPENDING) a reagovat na ně tím, že se například znovu pokusíte zpracovat stejnou zprávu v jiném spotřebiteli.
Když nepoužíváte skupiny, redis server se nemusí "posunout dál", "potvrzení" se stane 100% klientskou/obchodní logikou.