CodeParkXGROUP CREATE orders billing $ MKSTREAM
XADD orders * orderId 42 total 99.5
XREADGROUP GROUP billing worker-1 COUNT 10 BLOCK 5000 STREAMS orders >
XACK orders billing 1727950000000-0
XAUTOCLAIM orders billing worker-2 60000 0-0 COUNT 10
A consumer group shares the stream's entries between workers. If a worker crashes before it acknowledges an entry, the entry stays pending, and another worker can claim it later.
How the group shares work:
- The group remembers a last-delivered ID: the newest entry it has handed out.
- Each
XREADGROUP ... >call gives a consumer entries that no other member of the group has received. So the workers share the load. - Different groups each get every entry.
What happens on a crash:
- Each delivered entry goes into the group's pending entries list (PEL). It stays there until the consumer calls
XACKto confirm it. - If a consumer crashes, its entries stay pending.
XPENDINGshows these entries, with their idle time and how many times they were delivered.- Once an entry has been idle long enough, another consumer can take it over with
XCLAIMorXAUTOCLAIM.
This gives at-least-once delivery: an entry may be processed more than once. So handlers must be idempotent, which means running them twice has the same effect as running them once. Some entries keep failing. You can see this from a high delivery count. Move those entries to a dead-letter stream: a separate stream for messages that need a human or special handling.
- A group tracks a last-delivered ID, and
>reads entries the group has not delivered yet. - Inside one group, each entry goes to only one consumer.
- Delivered entries stay in the pending entries list until
XACK. XPENDINGandXAUTOCLAIMorXCLAIMrecover the work of a crashed consumer.- Delivery is at-least-once, so handlers must be idempotent.
Read more