Na podstawie podanego przykładu i pseudokodu wyobraźmy sobie, że:
recipient.user1otrzymuje 60 wiadomości na minutę- i
perform_task()wykonanie tej metody zajmuje 2 sekundy.
To, co się tutaj wydarzy, jest oczywiste:opóźnienie między przybyciem nowej wiadomości a jej przetworzeniem będzie tylko rosło z czasem, oddalając się od „przetwarzania w czasie rzeczywistym”.
system throughput = 30 messages/minute
Aby obejść ten problem, możesz utworzyć grupę konsumentów dla user1 . Tutaj możesz mieć 4 różne procesy Pythona działające równolegle ze wszystkimi 4 dołączonymi do tej samej grupy dla user1 . Teraz, gdy przychodzi wiadomość dla user1 jeden z 4 pracowników odbierze go i perform_task() .
system throughput = 120 message/minute
W twoim przykładzie message.acknowledge() tak naprawdę nie istnieje, ponieważ twój czytnik strumienia jest sam (polecenia XREAD).
Gdyby to była grupa, potwierdzenie wiadomości staje się niezbędne, dzięki czemu redis wie, że jeden z członków grupy faktycznie obsłużył tę wiadomość, więc może „ruszyć” (może zapomnieć o fakcie, że ta wiadomość czekała na potwierdzenie) . Podczas korzystania z grup istnieje trochę logiki po stronie serwera, aby zapewnić, że każda wiadomość zostanie dostarczona do jednego z pracowników grup konsumentów raz (polecenia XGROUPREAD). Kiedy klient skończy, wydaje potwierdzenie tej wiadomości (polecenia XACK), aby po stronie serwera „bufor grupy konsumentów” mógł ją usunąć i przejść dalej.
Wyobraź sobie, że pracownik zmarł i nigdy nie potwierdził wiadomości. Dzięki grupie konsumentów możesz uważać na tę sytuację (używając poleceń XPENDING) i działać na nią, na przykład próbując ponownie przetworzyć tę samą wiadomość u innego konsumenta.
Gdy nie używasz grup, serwer redis nie musi „przejść dalej”, „potwierdzenie” staje się w 100% logiką po stronie klienta/biznesu.
