Med exemplet och pseudokoden du har angett, låt oss föreställa oss att:
recipient.user1får 60 meddelanden per minut- och
perform_task()Metoden tar 2 sekunder att utföra.
Vad som kommer att hända här är uppenbart:fördröjningen mellan att ett nytt meddelande kommer in och att det bearbetas kommer bara att växa med tiden och glida längre och längre från "realtidsbearbetning".
system throughput = 30 messages/minute
För att komma runt detta kanske du vill skapa en konsumentgrupp för user1 . Här kan du ha 4 distinkta pythonprocesser som körs parallellt med alla 4 förenade i samma grupp för user1 . Nu när ett meddelande kommer in för user1 en av de fyra arbetarna hämtar den och perform_task() .
system throughput = 120 message/minute
I ditt exempel, message.acknowledge() existerar faktiskt inte, eftersom din stream-läsare är ensam (XREAD-kommandon).
Om det var en grupp, blir bekräftelsen av meddelanden väsentlig, det är så redis vet att en av gruppmedlemmarna faktiskt hanterade det meddelandet, så det kan "gå vidare" (det kan glömma det faktum att meddelandet väntade på bekräftelse) . När du använder grupper finns det lite logik på serversidan för att säkerställa att varje meddelande levereras till en av konsumentgruppens anställda en gång (XGROUPREAD-kommandon). När klienten är klar, utfärdar den en bekräftelse på det meddelandet (XACK-kommandon) så att serversidans "konsumentgruppsbuffert" kan radera det och gå vidare.
Tänk om en arbetare dog och aldrig erkände meddelandet. Med en konsumentgrupp kan du se upp för denna situation (med hjälp av XPENDING-kommandon) och agera på dem genom att till exempel försöka bearbeta samma meddelande i en annan konsument.
När du inte använder grupper behöver inte redis-servern "gå vidare", "bekräftelsen" blir 100 % klientsida/affärslogik.