APPENDIX · P11 · REDIS · QUEUE · FOR SLIDE 13
← Back to Slide 13
P11. A Reliable Queue: Redis Streams
# очередь матчмейкинга на Stream
DEL lesson03:mm:queue
XADD lesson03:mm:queue 1-1 player_id 1042 mode ranked
XADD lesson03:mm:queue 1-2 player_id 2001 mode ranked
XGROUP CREATE lesson03:mm:queue matchers 0
XREADGROUP GROUP matchers worker-1 COUNT 10 STREAMS lesson03:mm:queue >
XACK lesson03:mm:queue matchers 1-1
XPENDING lesson03:mm:queue matchers
XAUTOCLAIM lesson03:mm:queue matchers worker-2 0 0-0 COUNT 10
XACK lesson03:mm:queue matchers 1-2
XPENDING lesson03:mm:queue matchers
What the result should be
"1-1" "1-2" OK
worker-1 received 1-1 and 1-2
(integer) 1 // 1-1 confirmed
1) 1 2) "1-2" … // 1-2 is still in progress
// at worker-1
worker-2 claimed 1-2 // XAUTOCLAIM
(integer) 1
1) 0 … // nothing is pending
Consumer group
XACK
XAUTOCLAIM
Each message is assigned to a single group handler; the group keeps track of what has been dispatched.
XPENDING retains its status until XACK; a handler failure allows for a retry. Without RDB/AOF, a Redis restart loses the thread.
After a worker failure, redelivery is possible; processing must be idempotent. This is not a safeguard against Redis loss.
XACK deletes the pending link, not the stream record. There is no RDB/AOF in the lab; persistence and a retention policy are needed: MAXLEN can remove the body of a message that has not yet been acknowledged.