All 75 Redis quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 20 subtopics, so you can revise one part at a time. Choose Try Redis quiz above to take a scored run and review the questions you got wrong.
A.Wide columns where each row has a different set of columns
B.Key-value, with each value belonging to one of the built-in types
C.Nested JSON documents queried by path
D.Tables and rows with a fixed schema like a relational database
Answer: B
Key-value, but with typed values: string, list, hash, set, sorted set, stream. This is what separates it from a plain string cache — you can increment a number, push onto the end of a list, or fetch the top N of a sorted set without reading the whole value back into the application.
After setting a TTL on a key, does a plain SET overwrite keep that TTL?
A.The TTL is lost — the key becomes non-expiring
B.Redis errors because the key currently has a TTL
C.The TTL is preserved exactly as it was before the new value was written
D.The TTL is reset to the value originally set
Answer: A
The TTL is lost.SET overwrites both the value and the time-to-live metadata, so the key becomes permanent. This is a very common cause of caches that balloon and never shrink: code refreshes the cache with a plain SET and silently drops the expiry.
Two processes count views on the same key. Which approach is correct?
A.Take an application-level lock around the GET/SET
B.Use INCR — Redis performs the increment atomically on the server
C.Give each process its own key and sum them when reading
D.GET, add in the application, then SET the new value
Answer: B
Use INCR. Every Redis command is atomic because it runs on a single thread, so INCR has no read-modify-write gap. Reading and adding in the application is the classic lost-update mistake.
What is the risk of exposing Redis on port 6379 to the internet without a password?
A.Redis blocks connections from outside the local network itself
B.It can only be read but not written without a password
C.There is no risk if the data is only a cache
D.Anyone can read, delete the data and change the configuration
Answer: D
Full control: read all data, FLUSHALL, change config via CONFIG SET. Caches often hold session tokens, so you also lose the ability to impersonate users. At minimum: bind to an internal network, set a password, and disable/rename dangerous commands.
Redis suddenly got slow — what should you look at first?
A.SLOWLOG and INFO
B.Restart the Redis process and watch for a while
C.Double maxmemory
D.Add a replica to share the read load
Answer: A
SLOWLOG GET shows which commands exceeded the time threshold, and INFO shows memory used, hit rate, connection count, and persistence/replication state. These two commands usually point straight at the cause.
What is the main benefit of storing web sessions in Redis?
A.Sessions are never lost because Redis is always durable
B.Redis encrypts sessions automatically so they are much safer
C.Users no longer need a cookie because the session lives on the server
D.Every instance reads one source, so sticky sessions are no longer needed
Answer: D
Sessions are decoupled from the application process: every instance reads the same place, so no sticky session is needed and deploys or scaling don't log users out. Redis TTL is also exactly the session lifetime.
Which command reads a value and deletes the key in one step?
A.GETDEL in a single command
B.GETSET with an empty value
C.GET followed immediately by DEL
D.EXPIRE key 0 after the GET
Answer: A
GETDEL (Redis 6.2+). Used for values consumed exactly once: OTP codes, password reset tokens, idempotency keys. A single command so nobody can read it twice.
keyspace_hits and keyspace_misses in the stats section: hit rate = hits / (hits + misses). These are cumulative since startup, so to track them over time you have to take the difference between two measurements.
B.Cache the "not found" result briefly, or use a membership filter
C.Validate the key format at the application layer
D.Increase the expiry on the existing keys
Answer: B
Redis executes commands in a single thread on an event loop, which makes each command atomic without locks and free of data races. Since Redis 6, network I/O can be multithreaded, but command execution remains sequential.
You store a session with several fields and update them individually. Which type fits?
A.Set the producer to send synchronously
B.Sort the messages by a key so related messages share a partition
C.Use a single partition for the whole topic
D.Have the consumer sort by timestamp after reading
Answer: B
Use a Hash: HSET session:abc user_id 42 last_seen 1700000000. Each field is updated with one command instead of reading and rewriting the whole object, avoiding two requests overwriting each other.
When is a key with an expired TTL actually removed from memory?
A.The consumer group is misconfigured so the messages are duplicated
B.The consumer count exceeds the partition count so some sit idle
C.The broker limits how many consumers may connect
D.The messages are too large so the consumers cannot keep up
Answer: B
Redis uses two mechanisms: lazy expiration (the check and delete happen when the key is next accessed) and active sampling (periodically picking random keys with TTLs and deleting expired ones). So an expired key can still occupy memory for a while.
Why is KEYS pattern considered dangerous in production?
A.It requires administrative privileges so it is easy to abuse
B.It walks the entire keyspace and blocks the server
C.It returns keys that have expired but not yet been deleted
D.It appends to the AOF file, making that file grow
Answer: B
KEYS scans the entire keyspace in a single execution. Since Redis is single-threaded, every other client is blocked until it finishes — hundreds of milliseconds to seconds on millions of keys. Use SCAN to iterate with a cursor, a small batch at a time.
How do SET key value EX 60 and SETEX key 60 value differ?
A.SETEX is faster because it has fewer arguments to parse
B.SET with EX does not overwrite an existing key
C.They are the same, but SET carries more options
D.SETEX preserves the existing TTL while SET resets it
Answer: C
Both commands give the same result. SET is more modern because it combines several behaviours in one command: EX/PX for the TTL, NX/XX for existence conditions, KEEPTTL to preserve the existing TTL. Prefer SET with options over the older specialised commands.
Compared with Memcached, what is Redis's main advantage?
A.Many data types, plus persistence and replication
B.Read and write speeds several times faster
C.Lower memory consumption for the same amount of data
D.Multithreading, so it uses the CPU better
Answer: A
Redis is stronger in capabilities: multiple data types, persistence, replication, Pub/Sub, Streams, Lua scripting. Memcached is simpler, multithreaded, and more memory-efficient for pure string caching. For new systems, Redis is usually chosen because it covers more needs.
You need daily unique visitor counts over tens of millions of hits. Which structure is most efficient?
A.HyperLogLog, using roughly 12KB per counter
B.A Bitmap with one bit per user
C.A Set holding every user identifier for the day
D.A Hash with one field per user
Answer: A
HyperLogLog: PFADD visitors:2026-08-17 user:42 and PFCOUNT to get the count. Fixed memory of about 12KB per counter regardless of element count, with roughly 0.81% error. You can also merge multiple days with PFMERGE.
Do Redis MULTI/EXEC transactions support rollback?
A.Yes, provided every command in the block touches the same key
B.Yes, but the option must be enabled in the configuration file
C.No — a failing command does not undo the earlier ones
D.Yes — the whole block is discarded if any command fails
Answer: C
There is no rollback. If a command fails at runtime (for example calling INCR on a string key), the remaining commands still execute and the earlier commands keep their effects. Only syntax errors caught while queuing cause the whole block to be rejected.
B.The key's deadline is being recalculated after a write
C.The key does not exist in the current database
D.The key has just expired but has not been removed from memory yet
Answer: A
-1 means the key exists but has no expiry; -2 means the key does not exist. Distinguishing these two matters when auditing cache keys that were left without a TTL.
Does Redis support multiple logical databases on one instance?
A.Yes, but only when cluster mode is enabled
B.Yes — numbered from 0 and switched with the SELECT command
C.No — an instance has only one keyspace
D.Yes, and each database runs in its own process
Answer: B
Yes, 16 databases numbered from 0 by default, selected with SELECT n. But they share the same process, memory, and execution thread — so this is not a way to isolate load. Cluster mode only supports database 0.
You need to check whether a key exists without fetching its value. Which command?
A.TYPE key and compare against the empty string
B.GET key and then check whether the result is empty
C.SCAN with a pattern matching the exact key name
D.EXISTS key, which returns how many of the keys were found
Answer: D
EXISTS key returns 1 if the key exists, 0 if not. It accepts multiple keys at once and returns the count of keys found, so EXISTS a b c returning 2 means two of the three keys exist.
Redis executes commands on a single thread — why is it still fast?
A.It runs commands in parallel across cores using SIMD
B.The data lives in RAM and each command takes only microseconds
C.It spawns a separate thread for each client connection sending commands
D.It compresses the data so fewer bytes are read and written
Answer: B
Because the data lives in RAM and each command costs only a few microseconds, so a single thread can still serve hundreds of thousands of commands per second. Single-threading is also a feature: every command is atomic, no locks are needed, and latency stays consistent.
A.It requires admin privileges so it is usually blocked
B.It scans the entire keyspace in one command and blocks the server
C.It returns at most 1000 keys so results are incomplete
D.It clears the TTL of the listed keys
Answer: B
Because it scans the entire keyspace in one command, and Redis has a single execution thread — every other client has to wait. On a few million keys, the blocking time is enough to cause mass timeouts. Use SCAN with a cursor to break it up.
What is the core difference between RDB and AOF persistence?
A.RDB is for the primary while AOF is only for replicas
B.RDB writes to disk while AOF only stays in the process's memory
C.RDB snapshots the data periodically while AOF records each write command
D.RDB compresses the data while AOF never does
Answer: C
RDB is a periodic snapshot of all data; AOF is a log of write commands. RDB gives compact files and fast restarts but loses data since the last snapshot; AOF loses the least (usually ≤1 second with everysec) but the file is larger and slower to load.
Redis hits maxmemory with policy noeviction. What happens to the next write?
A.The Redis process restarts itself to free memory
B.Writes return an error while reads continue to be served
C.Redis deletes the oldest keys in the keyspace to make room
D.Redis spills to disk as virtual memory
Answer: B
The write command fails (OOM), reads still run. If Redis is acting as a cache, noeviction is the wrong policy — set allkeys-lru so it evicts entries itself. noeviction is only correct if Redis holds data that must not be lost (queues, mandatory sessions).
What is the sequence of the cache-aside (lazy loading) pattern?
A.Preload the entire dataset into the cache at application startup
B.Read the cache; on a miss read the DB, write it into the cache, then return
C.Write to the cache and the DB simultaneously on each write
D.Write to the cache first and let it sync down to the DB afterwards
Answer: B
Read cache → on miss read DB → write to cache (with TTL) → return the result. The application manages the cache actively, so if the cache dies the system still runs, just slower.
B.Running the commands in parallel across the server's threads
C.Sending many commands without waiting for each reply, cutting the round trips
D.Wrapping several commands into one atomic transaction on the server
Answer: C
Send many commands in a row without waiting for each reply, then read all the replies. Network latency is usually the dominant cost in Redis, so batching 1000 commands into one pipeline is over a hundred times faster than sending them individually.
If one command inside MULTI/EXEC fails at runtime, what happens to the rest?
A.The whole block is rolled back to its exact prior state
B.Redis retries the failing command until it succeeds
C.The block stops at the failing command and the rest are skipped
D.The other commands still run — Redis does not roll back
Answer: D
The remaining commands still run — Redis does not roll back. The reply of EXEC is an array, and the corresponding element contains the error. This is what makes Redis "transactions" unlike SQL transactions.
A leaderboard needs top-10 reads and constant score updates. Which data type fits?
A.A hash — one field per player
B.A string — store the whole leaderboard as JSON
C.A list — push new scores at the head and read out 10 elements
D.A sorted set — members are kept ordered by score
Answer: D
Sorted set. Each element has a score and Redis keeps them ordered by score, so ZREVRANGE key 0 9 WITHSCORES gives the top 10 directly, ZINCRBY increments a score atomically, and ZREVRANK gives a person's rank.
What does Redis replication guarantee about data on a replica?
A.Asynchronous — a replica may lag behind the primary
B.Replicas are writable and sync bidirectionally with the primary
C.Each replica holds part of the data to share the memory load
D.Synchronous — a write only returns once every replica acknowledges
Answer: A
Asynchronous. The primary returns OK to the client before pushing commands to the replicas, so replicas can lag and some of the last writes may be lost if the primary dies at that moment.
What is the core difference between Redis Pub/Sub and Streams?
A.A Stream allows one consumer while Pub/Sub allows many
B.Pub/Sub is faster because it uses UDP
C.Pub/Sub does not retain messages while Streams do
D.Pub/Sub guarantees exactly-once delivery
Answer: C
Pub/Sub is fire-and-forget: anyone not listening at the time loses the message. Streams persist messages with increasing ids, support consumer groups and processing acknowledgements, so you can re-read and know which messages are still pending.
What problem does a single hash key with 5 million fields cause?
A.Redis refuses to create a hash with more than a million fields in one key
B.Any command touching the whole key blocks the server, and the key lives on one node
C.The hash converts itself into a sorted set to cope with the load
D.Fields beyond the limit are evicted by LRU
Answer: B
This is a big key: HGETALL or DEL on it blocks the single thread for tens to hundreds of ms, and in a cluster the whole key must live on one node, making that node a hotspot. Splitting it into multiple keys by group is the fix.
C.Redis runs out of memory so every subsequent write returns an error
D.A hot key expires and many concurrent requests all go down to the DB
Answer: D
When a hot key expires, a flood of concurrent requests all miss and hit the DB together. Worse is when many keys expire at the same moment because they were loaded at the same time with equal TTLs.
B.Exactly at the expiry second thanks to a per-key timer
C.When something accesses it, plus a sampling background scan
D.Only when memory reaches the configured maxmemory
Answer: C
Two combined mechanisms: lazy — an expired key is deleted when someone accesses it; and active — Redis randomly samples keys with a TTL and deletes the expired ones. So memory doesn't drop the exact second a key expires.
For a simple list-based work queue, which command should the consumer use?
A.BRPOP — block until work arrives instead of polling
B.RPOP in a loop with a short sleep between calls
C.SUBSCRIBE to a channel named after the queue
D.LRANGE and skip the elements already handled
Answer: A
BRPOP — it blocks until an element is available or the timeout expires, so the consumer doesn't have to poll. Push work with LPUSH, pop with BRPOP is the basic FIFO queue pattern.
Limiting each user to 100 requests per minute with Redis — what is the tidiest approach?
A.Count in each application instance's memory and add them up
B.Write every request to the DB and count with a query
C.Store the list of every timestamp and count them on each call
D.INCR a key keyed by the minute, setting a 60-second TTL on the first hit
Answer: D
Fixed window: a key like rl:<user>:<minute>, INCR on each request, and if it returns 1 then EXPIRE 60. The key expires on its own so no cleanup is needed. Wrap both commands in Lua if you want to be absolutely sure the TTL is always set.
Counting daily unique users where a small error is acceptable — what uses the least memory?
A.A list recording each visit, deduplicated on read
B.A HyperLogLog through PFADD/PFCOUNT
C.A string incremented with INCR on each visit
D.A set holding the ids of every user who visited that day
Answer: B
HyperLogLog: PFADD adds elements, PFCOUNT returns the unique count with about 0.81% error. Each key costs only ~12KB even when counting a billion ids — trading absolute accuracy for nearly fixed memory.
A.Monitoring, detecting a dead primary, and promoting a replica automatically
B.Load-balancing requests between the primary and the replicas
C.Splitting data across nodes to scale total memory
D.Backing the data up periodically to external storage
Answer: A
Monitoring and automatic failover: multiple Sentinel processes watch together, and once enough agree that the master is dead, they promote a replica to master and notify clients. It does not shard data — that's Cluster's job.
After a database update, should you delete the cache key or write the new value into it?
A.Delete the key and let the next read reload it from the DB
B.Do nothing and wait for the TTL to expire
C.Flush the entire cache to be certain of consistency
D.Write the new value into the cache so the next read need not touch the DB
Answer: A
Delete the key (cache invalidation). Writing the new value straight into the cache sounds more efficient but easily leaves stale data: two concurrent updates can write the cache in the reverse order of the DB writes.
Storing a read/unread flag for 10 million users — the most memory-efficient way?
A.A single hash with ten million fields
B.A bitmap: SETBIT at the position equal to the user's id
C.A separate string key per user holding "0" or "1"
D.A set holding the ids of the users who have read it
Answer: B
Bitmap: SETBIT notif:42:read <userId> 1. 10 million bits ≈ 1.2MB, BITCOUNT gives the number of users who have read, BITOP combines multiple bitmaps. The condition is that user ids must be consecutive integers or mappable to numbers.
An application opens a new Redis connection per request. What is the problem?
A.Each connection creates its own separate database
B.Redis returns stale data on a new connection
C.The handshake cost each time plus the risk of exhausting the allowed connections
D.There is no problem; Redis handles unlimited connections
Answer: C
Each connection costs handshake time (TCP, authentication) plus its own buffer, and the connection count is also bounded by maxclients. Under high load the app becomes both slow and refused. Use a connection pool.
Choosing a cache: what is the clearest difference between Redis and Memcached?
A.Memcached persists data durably while Redis does not
B.Redis has no per-key TTL while Memcached does
C.Memcached supports transactions while Redis does not
D.Redis has data types, persistence and replication; Memcached does not
Answer: D
Redis has data types (list, hash, sorted set, stream), persistence, replication, scripting. Memcached is a flat key-value, multithreaded, extremely lean store — still great if you only need to cache strings and want to use many cores.
What does appendfsync everysec mean in terms of data loss?
A.At most about one second of the last writes is lost on a power failure
B.The operating system decides and Redis has no control
C.Everything since the last RDB snapshot is lost
D.Nothing is lost because every write is fsynced
Answer: A
Redis calls fsync once per second, so a power loss loses at most about the last second of writes. This is the default because always (fsync on every command) is much slower, while no depends entirely on the operating system.
Ensuring a webhook is processed once despite sender retries — how with Redis?
A.Store processed ids in a list and search the list
B.Rely on the cache's TTL to deduplicate by itself
C.EXISTS first and then SET if absent
D.SET <event-id> 1 NX EX <ttl>, processing only when the command returns OK
Answer: D
Idempotency key: SET webhook:<event-id> 1 NX EX 86400. An OK reply means it's the first time — process it; a nil reply means it already exists — skip it. A single command means two parallel retries can't both win.
A delayed queue (process 10 minutes later) is built with which Redis structure?
A.A list with BRPOP and a 10-minute sleep in the consumer
B.A stream with the write time set 10 minutes ahead
C.A key with a 10-minute TTL and catching the expiry event
D.A sorted set scored by the time the job should run
Answer: D
A sorted set with the score being the timestamp to run at: ZADD delayed <runAt> <jobId>. The worker calls ZRANGEBYSCORE to fetch elements with score ≤ now, then ZREM to claim the job.
In Redis Cluster, MGET user:1 user:2 user:3 returns a CROSSSLOT error. Why?
A.The cluster only allows one key per command for consistency
B.The keys hash to different slots and may live on different nodes
C.MGET is not supported in cluster mode
D.The key count exceeds the limit for one command
Answer: B
Because the three keys hash to three different slots, possibly on three nodes — a single command can't run across multiple nodes. Fix: the hash tag user:{1} doesn't help here, so either issue three separate commands (pipeline), or design keys so that a group read together shares the same tag.
What should you do when a query legitimately returns "no result" and you are caching it?
A.Cache the empty result too, but with a shorter TTL than usual
B.Do not cache anything, since caching an empty value is pointless
C.Delete the related key so the next read definitely hits the DB
D.Cache the empty result with the same long TTL as real data
Answer: A
Cache the empty value too, but with a short TTL (tens of seconds to a few minutes). Otherwise anyone repeatedly calling non-existent ids pushes the whole load down to the DB — this is called cache penetration.
A.The application writes to the cache and the cache flushes to the database
B.The application writes to the cache and the database together on every update
C.The application reads the cache first, and on a miss reads the database then writes the cache
D.The cache reads the database itself when it finds a key missing
Answer: C
The application reads the cache first; on a miss it queries the database, writes the result into the cache with a TTL, and returns it. When data changes, the application deletes the cache key rather than overwriting it. This is the most common pattern because it is simple and tolerates cache failure.
Why is INCR safer than reading a value and writing it back?
A.It writes straight to disk so no data is lost
B.It locks the key for the duration of the operation
C.It retries automatically when it detects a conflict
D.It performs the read and the write in one atomic command
Answer: D
A GET followed by SET has a gap: two clients both read the value 10, both write 11, and one increment is lost. INCR performs both steps in a single atomic command, so two clients calling it together get 12.
How do the allkeys-lru and volatile-lru eviction policies differ?
A.allkeys-lru only kicks in once memory exceeds twice the limit
B.allkeys-lru deletes random keys to save computation
C.volatile-lru only evicts keys that have a TTL set
D.volatile-lru evicts keys in the order they were created
Answer: C
Both evict the least recently used key, but volatile-lruonly considers keys with a TTL. If Redis is used both as a cache and to hold data that must be kept, volatile-lru is safer; if it's used purely as a cache, allkeys-lru fits better.
How do RDB and AOF differ in data loss protection?
A.AOF cannot be used at the same time as RDB on one instance
B.RDB is safer because it saves the whole state on every write
C.AOF records each command so it loses less data than RDB
D.Both give the same guarantee and differ only in file format
Answer: C
RDB takes periodic snapshots: fast restart, compact file, but all changes since the last snapshot are lost. AOF logs every write command and usually loses less data, but the guarantee depends on appendfsync, in exchange for a larger file and slower restart. Systems needing high durability usually enable both.
A leaderboard needs the top 10 and any user's rank. Which data type fits?
A.A Sorted Set, since rank lookup and top-N are both very fast
B.A Set with the score packed into the value string
C.A List kept pre-sorted by score
D.A Hash holding each person's score, sorted when needed
Answer: A
Sorted Set: ZADD leaderboard 1500 user:42 to record a score, ZREVRANGE leaderboard 0 9 WITHSCORES to get the top 10, ZREVRANK leaderboard user:42 to look up a rank. Both operations are logarithmic in cost, so it fits leaderboards with millions of users.
A.It guarantees the group of commands executes as one atomic block
B.It compresses the transmitted data to save bandwidth
C.It reduces the number of network round trips when sending many commands
D.It lets Redis execute the commands in parallel across cores
Answer: C
Pipelining sends many commands in one round trip instead of waiting for a reply to each one. With 1ms network latency, 100 sequential commands take about 100ms while a pipeline takes only a few milliseconds. Note: it does not make the batch atomic.
How should a distributed lock in Redis be implemented correctly?
A.SET key value NX PX ttl with a unique identifier as the value
B.GET to check whether the key exists, then SET if not
C.SETNX followed by EXPIRE in the next command
D.INCR a counter and treat the value 1 as having taken the lock
Answer: A
Use SET lock:resource <random-token> NX PX 30000: a single atomic command that both acquires the lock and sets its expiry. Release must use a Lua script that verifies the token matches before deleting, so you don't delete a lock currently held by another process.
What fundamentally distinguishes Redis Pub/Sub from Streams?
A.Pub/Sub guarantees ordering while Streams do not
B.Streams only work in Redis Cluster
C.Streams retain messages while Pub/Sub does not
D.Pub/Sub supports many consumers while Streams support only one
Answer: C
Pub/Sub is fire-and-forget: if a subscriber isn't connected when the message is published, it's lost. Streams persist messages in order, have consumer groups, an acknowledgement mechanism, and can be re-read — so they work as a reliable queue.
Redis memory keeps growing while business data stays flat. What is the likeliest cause?
A.Many keys are created without a TTL
B.Redis retains the history of the commands it has run
C.The AOF file grows and increases the process's memory
D.The number of client connections grows over time
Answer: A
The first suspect is keys without a TTL: cache written with SET while forgetting EX, or some key prefix that keeps being created and never expires. Check with INFO memory, --bigkeys, and MEMORY USAGE on the suspect keys.
What mistake should be avoided when implementing rate limiting with Redis?
A.Returning a header telling the client how much of the limit remains
B.Setting the TTL to exactly the length of the limit window
C.Using a separate key for each user
D.Splitting the increment and the expiry into two separate commands
Answer: D
The most common mistake is INCR followed by EXPIRE as a separate command: if the process dies between the two commands, the counter lives forever and the user is blocked forever. Use a Lua script to do both atomically, or SET key 0 EX ttl NX first and then INCR.
B.It records the key's change history for later comparison
C.It aborts the block if a watched key is modified
D.It notifies the client when a watched key changes
Answer: C
WATCH key marks the key to monitor. If another client changes that key before EXEC runs, the whole block is aborted and returns a null reply — the application must detect this and retry. This is optimistic concurrency control, with no locks.
Why does storing a million small keys use far more memory than expected?
A.Memory is reserved in advance for the data to grow into
B.The key name is stored repeatedly in several internal structures
C.Redis always allocates at least one kilobyte per key
D.Each key carries metadata and an entry in the hash table
Answer: D
Each key carries a fixed overhead of a few dozen to over a hundred bytes: the object structure, pointers, the hash table entry, and the TTL if present. With values of only a few bytes, the overhead exceeds the data itself — so grouping many small values into one hash is usually far more economical.
Using a List as a job queue, which command prevents job loss if a worker dies?
A.LRANGE to read then LREM after processing finishes
B.LPOP with a log entry written before processing
C.BRPOP with a long enough timeout
D.BLMOVE transferring it to a processing list
Answer: D
BLMOVE queue processing LEFT RIGHT 5 takes a job and moves it to the processing list in a single atomic operation. If a worker dies mid-way, the job still sits in processing, and a supervisor process can push it back to the queue.
What are Redis keyspace notifications for, and what is their limitation?
A.They emit events when keys change, with no delivery guarantee
B.They record a change history for querying later
C.They automatically delete related keys when one key changes
D.They synchronize data to another Redis in real time
Answer: A
Keyspace notifications emit events via Pub/Sub when a key is written, deleted, or expires. Useful for cleaning up related data or reacting when a session expires. Major limitation: fire-and-forget — a client that loses its connection will never receive the events it missed.
What matters most when using Redis as a session store?
A.Storing all the user's information in the session to reduce queries
B.Turning off persistence to speed up session reads and writes
C.Setting a very long TTL so users never have to log in again
D.Choosing an eviction policy so sessions are not dropped when memory fills
Answer: D
The most important thing is separating session configuration from cache configuration: if you share one instance with allkeys-lru, active sessions can be evicted when memory is full and users get logged out. Separate the instance, or use volatile-lru with a TTL set on every cache key.
You need shops within 5km of a user. How does Redis support this?
A.The GEO commands, built on a Sorted Set with geohash encoding
B.Use a bitmap to mark geographic grid cells
C.Redis has no spatial support so it must be handled in the application
D.Store the coordinates in a hash and filter with a Lua script
Answer: A
Use the GEO command group: GEOADD shops 106.7 10.77 shop:1 to add, and GEOSEARCH shops FROMLONLAT 106.7 10.77 BYRADIUS 5 km ASC to search by radius. Underneath it is a Sorted Set whose scores are 52-bit geohash codes.
A.It shards the data across nodes to scale capacity
B.It load-balances read queries across the replicas
C.It backs up the data periodically to external storage
D.It monitors, detects failure and promotes a replica
Answer: D
Sentinel is a monitoring and failover system: it watches the master and replicas, confirms failures through consensus among multiple Sentinels, promotes a replica, and updates the configuration for the rest. Clients ask Sentinel for the current master address.
When database data changes, should you update or delete the corresponding cache key?
A.Delete it, so the next read reloads the correct value
B.Update it, so the next read avoids querying the database
C.Update it if the value is small, delete it if the value is large
D.Do nothing, since the TTL will handle it
Answer: A
You should delete (invalidate) rather than update. With updates, two concurrent requests can write the cache in the reverse order of the database writes, leaving the cache holding a stale value until it expires. With deletion, the next read always reloads the correct value.
Which metric best reflects Redis cache effectiveness?
A.The hit ratio over total lookups
B.How much memory the instance is using
C.The number of open client connections
D.The number of commands the server handles per second
Answer: A
The cache hit ratio, computed from keyspace_hits and keyspace_misses in INFO stats. A low ratio means the cache isn't reducing database load — possibly due to too-short TTLs, keys evicted too early, or an access pattern that doesn't repeat.
What problem does Redis 6 client-side caching (tracking) solve?
A.It compresses data before transmission to reduce bandwidth
B.It removes the network round trip for very frequently read keys
C.It automatically spreads read load across the replicas
D.It lets clients buffer writes while disconnected from the server
Answer: B
The client keeps a local copy of the keys it has read; the server tracks them and sends invalidation notifications when a key changes. Hot keys are then read straight from process memory, eliminating network latency entirely — a two-tier cache model.
How do you use Redis to ensure a payment request is not processed twice?
A.Store an idempotency key with SET NX plus an expiry
B.Count the calls with INCR and block anything above one
C.Store the request identifier in a list and check it when needed
D.Check the key with EXISTS and write it if it is absent
Answer: A
Use SET idem:<key> <status> NX EX 86400: only the first request succeeds and is allowed to be processed; duplicates get the stored value back. Once processing finishes, overwrite the key with the result so repeated calls return the same original response.
B.Commands whose execution time exceeded the configured threshold
C.Connections dropped for exceeding the timeout
D.Every command that has run, along with each one's timing
Answer: B
SLOWLOG stores commands whose execution time exceeds slowlog-log-slower-than (10,000 microseconds by default). It does not count network transfer time or queueing time, so it captures only the commands that actually consumed execution time.
Along which dimensions do Redis 6 ACLs restrict access?
A.Only by the connecting client's IP address
B.By how many commands per second each user issues
C.By which logical database the user may select
D.By command, by key pattern and by Pub/Sub channel
Answer: D
ACLs restrict along three dimensions: commands (+get +set -flushall or by category like +@read), key patterns (~cache:*), and Pub/Sub channels (&events:*). This lets each service have its own account with exactly the permissions it needs.
What notable change did the RESP3 protocol (Redis 6) introduce?
A.Encryption of all traffic between client and server
B.Compression of reply data to reduce bandwidth
C.More reply data types and support for push messages
D.The ability to send several commands in a single packet
Answer: C
RESP3 adds richer reply types (map, set, double, big number, verbatim string) and push messages — the server can proactively send notifications on the same connection. This is the foundation for client-side caching and for receiving Pub/Sub without a separate connection.
A serverless application exhausts Redis connections. What is the root cause?
A.Redis limits connections per source IP address
B.The connections are closed for exceeding the default timeout
C.Serverless environments do not support persistent connections
D.Each function invocation opens a new connection and reuses nothing
Answer: D
Each function instance opens its own connection, and the number of instances scales with traffic, so the total connection count blows past maxconnections very quickly. The fix: declare the client at module scope so it's reused across invocations, and use a proxy or a connectionless HTTP endpoint.
You need feature flags for millions of users, dozens of flags each. What is efficient?
A.One hash per user holding all their flags
B.A Bitmap per flag, with one bit per user
C.A separate key for each user-and-flag pair
D.One set per flag holding the users it is enabled for
Answer: B
Use a bitmap per flag: SETBIT flag:new_ui 12345 1 enables it for user 12345, GETBIT checks it. A million users costs only about 125KB per flag, and BITCOUNT gives the number of enabled users without scanning.
What problem do consumer groups solve in Redis Streams?
A.Distributing messages across consumers and tracking their processing
B.Guaranteeing absolute processing order across consumers
C.Compressing old messages to save memory
D.Duplicating each message to every consumer in the group
Answer: A
A consumer group lets multiple consumers share the processing of a stream: each message is delivered to only one member, delivered-but-unacknowledged messages sit in a pending list, and XAUTOCLAIM reassigns them to another consumer when one dies.
How should an in-process cache and Redis work together?
A.The local cache for user data, Redis for shared data
B.Use only one of the two to avoid inconsistency
C.The local cache for rarely changing data, Redis for shared state
D.Write to both on every update so they stay in sync
Answer: C
Two-tier model: a local cache holds rarely-changing data with a very short TTL (a few seconds), and Redis holds the part shared across all instances. The local tier removes network latency for hot data, the Redis tier ensures every instance sees the same source.
How should maxmemory be set relative to the machine's RAM?
A.About half the RAM in every case
B.Below the machine's RAM, leaving room for needs outside the dataset
C.Leave it unset and let Redis manage it as needed
D.Exactly equal to the RAM to use it fully
Answer: B
Set it below the machine's RAM to leave room for: client output buffers, replication buffers, and especially the memory copy created when forking for a snapshot. With persistence enabled, around 50–60% of RAM is the usual figure; without it, you can go higher.
You need each user's 100 most recent activities. What is the cleanest approach?
A.LPUSH with a periodic job trimming the list
B.LPUSH followed by LTRIM keeping exactly 100 elements
C.A Sorted Set scored by timestamp
D.A separate key per activity with a TTL
Answer: B
LPUSH activity:user:42 <item> followed immediately by LTRIM activity:user:42 0 99. The list always keeps exactly the 100 most recent items, and LTRIM on a short list has very low cost. Combine the two commands in a pipeline or transaction to reduce network round trips.
