Part 2 · 1 chapters · ~8 min

The Single-Threaded Core

Why one thread executes commands, the ae event loop over epoll and kqueue, atomicity without locks, IO threads since Redis 6, slow commands that block everyone (KEYS, large deletes, big ranges), SCAN and UNLINK, the slow log and latency monitor, and big keys.

4

One thread, one loop

code
SLOWLOG GET 10                 # commands slower than slowlog-log-slower-than (µs)
LATENCY DOCTOR                 # latency events and advice
redis-cli --bigkeys            # find the largest keys (uses SCAN, safe in production)
SCAN 0 MATCH session:* COUNT 1000   # iterate keys without blocking (never KEYS in production)
UNLINK huge:set                # delete asynchronously in a background thread
THE SINGLE-THREADED CORE
one thread executes every command; helpers do IO and background work
clientsthousands of socketsIO threads (optional)read/parse, write repliesevent loopae: epoll / kqueuemain threadexecutes commands, one at a timebackground threadslazy free, fsync, closefork for RDB / AOF rewritecopy-on-write child
swipe the figure sideways, or tap expand for full screen
1/5
one command at a time
A single main thread executes every command, one after another. Each command is atomic by construction: no locks, no races between commands.
commands run one at a time, atomicallyno locks needed