С примера и псевдо кода, който сте дали, нека си представим, че:
recipient.user1получава 60 съобщения в минута- и
perform_task()методът отнема 2 секунди за изпълнение.
Това, което ще се случи тук, е очевидно:латентността между идването на ново съобщение и обработването му само ще нараства с времето, отклонявайки се все по-далеч от „обработката в реално време“.
system throughput = 30 messages/minute
За да заобиколите това, може да искате да създадете потребителска група за user1 . Тук можете да имате 4 различни процеса на Python, работещи паралелно, като всичките 4 са присъединени в една и съща група за user1 . Сега, когато дойде съобщение за user1 един от 4-те работници ще го вземе и perform_task() .
system throughput = 120 message/minute
Във вашия пример, message.acknowledge() всъщност не съществува, защото вашият четец на поток е сам (команди XREAD).
Ако беше група, потвърждението на съобщенията става от съществено значение, така redis знае, че един от членовете на групата всъщност е обработвал това съобщение, така че може да "продължи" (може да забрави факта, че това съобщение е чакало потвърждение) . Когато използвате групи, има малко логика от страна на сървъра, за да се гарантира, че всяко съобщение се доставя на един от работниците в потребителските групи веднъж (команди XGROUPREAD). Когато клиентът приключи, той издава потвърждение на това съобщение (команди XACK), така че „буферът на групата на потребителите“ от страна на сървъра може да го изтрие и да продължи напред.
Представете си, ако работник умре и никога не потвърди съобщението. С потребителска група вие сте в състояние да внимавате за тази ситуация (използвайки команди XPENDING) и да действате по тях, например като се опитате отново да обработите същото съобщение в друг потребител.
Когато не използвате групи, Redis сървърът не трябва да „продължава“, „потвърждението“ става 100% от страна на клиента/бизнес логика.
