All quizzesHard
Locking, Streams & Scripting — Series 3
Preview — 3 of 10 questions
What does XADD orders * customer_id 42 total 99.99 do with the * argument, and what does the resulting ID look like?
A* tells Redis to auto-generate the entry's ID, rather than the caller supplying one explicitly. The generated ID has the form <millisecond-timestamp>-<sequence> (e.g. 1735300000000-0), combining the current time with a per-millisecond sequence counter to guarantee IDs are always strictly increasing, even for multiple entries added within the same millisecond
B* is a wildcard meaning "match any existing entry"; this command updates every existing entry in the stream
C* means the entry has no ID at all and can never be individually referenced afterward
D* is only valid syntax when the stream already has at least one entry
Beyond consumer groups (XREADGROUP), how would you inspect a stream's contents directly — for debugging, or a simple one-off read with no group tracking involved?
AXLEN orders returns the total number of entries currently in the stream; XRANGE orders - + reads every entry from the very first (-) to the very last (+) ID, without touching or requiring any consumer group state at all — useful for debugging, one-off inspection, or any use case that doesn't need the "each entry delivered to exactly one consumer in the group" semantics groups provide
BStreams can only ever be read through a consumer group; there's no direct read mechanism
CXLEN and XRANGE both require first calling XGROUP CREATE, even for a simple direct read
DXRANGE always returns every entry ever added to the stream, ignoring any range arguments given
After XREADGROUP delivers a message to a consumer, and the consumer finishes processing it successfully, what step is needed to mark that message as done?
ANothing further is needed — once XREADGROUP delivers a message, it's automatically considered fully processed
BXDEL must be called to remove the message from the stream entirely, which is the only way to mark it processed
CXACK orders my_group message_id explicitly acknowledges that this specific message has been successfully processed, removing it from that consumer group's pending entries list (PEL) — without this step, the message stays in the PEL indefinitely, exactly as if it were still awaiting processing, which is precisely the state XPENDING/XCLAIM (from the earlier stream material) are built to detect and recover from
DXACK is only relevant when using XAUTOCLAIM; ordinary consumer group processing doesn't require it
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.