Redis设计与实现 (黄健宏)（Z-Library） (1)

# Redis设计与实现 — Reading Guide ## 【One-Line Pitch】 A systematic, source-code-level walkthrough of Redis's internal architecture—covering data structures, object system, database engine, persistence, and all multi-machine features—for backend engineers and NoSQL practitioners who want to understand not just *how* to use Redis but *why* it works the way it does. ## 【Book Arc】 - **Opening (~0%–3%)**: Author's origin story—building a "mutual follow" feature with SQL joins led him to Redis's native set operations. Sets up the book's mission: no comprehensive Chinese/English resource on Redis internals existed, so he annotated the source code himself, starting with Redis 2.6 and rewriting for 3.0. - **Early (~3%–13%)**: Foundational data structures—linked lists (doubly-linked, acyclic, type-specific functions), dictionaries (MurmurHash2, index calculation via sizemask, and the crucial *progressive rehash* mechanism that spreads O(N) work across operations to avoid server stalls), and skiplists (O(log N) average lookup, used only for sorted sets and cluster internals). - **Early (~13%–23%)**: Memory-optimized structures—integer sets with type *upgrade* logic, and compressed lists (ziplists) with their byte-level layout (zlbytes, zltail, zllen) and the O(N²) worst-case *cascade update* problem. Introduces the object system: every key/value is a `redisObject` with type, encoding, and pointer attributes. - **Early (~23%–32%)**: The polymorphic command dispatch system—type checking via `redisObject.type` (e.g., LLEN rejects non-list keys with WRONGTYPE), then encoding-based dispatch (ziplist vs. linkedlist implementations). Covers the LRU idle-time tracking and its role in maxmemory eviction policies. - **Middle (~32%–48%)**: Database internals—the `redisDb` structure with `dict` (key space) and `expires` (TTL) dictionaries; the dual deletion strategy (lazy `expireIfNeeded` on access + periodic `activeExpireCycle` with random sampling); master-slave expiration coordination; and RDB persistence (SAVE blocking vs. BGSAVE non-blocking, `dirty` counter + `lastsave` timestamp driving automatic saves via `serverCron`). - **Middle (~48%–52%+)**: AOF persistence—command append to `aof_buf` in protocol format, file write and sync steps, and (per chapter summaries) rewrite mechanisms that exclude expired keys. ## 【Key Takeaways】 - **Progressive rehash prevents latency spikes** (Early): Instead of one massive rehash, Redis migrates key-value pairs incrementally across normal operations using a `rehashidx` counter—new writes go to ht[1] while reads check both tables, ensuring ht[0] shrinks to empty without blocking the server. - **Encoding flexibility is the core optimization strategy** (Early): Every object type supports multiple encodings (e.g., list as ziplist or linkedlist; hash as ziplist or hashtable). Redis switches based on element count/size to balance memory efficiency (compact contiguous storage) against operational complexity—checkable via `OBJECT ENCODING`. - **Type checking + encoding dispatch = polymorphic commands** (Early): Commands like LLEN first verify the key's `type` attribute (rejecting wrong types with WRONGTYPE), then select the correct implementation based on `encoding`—a two-level polymorphism that lets one command serve multiple underlying structures. - **Expired-key deletion is a hybrid of lazy and active strategies** (Middle): `expireIfNeeded` filters expired keys on every access, while `activeExpireCycle` periodically samples random keys from the `expires` dictionary across databases—balancing CPU usage against memory waste without a dedicated timer thread. - **Master-slave expiration is centralized for consistency** (Middle): Masters delete expired keys and propagate DEL commands to replicas; slaves never delete on their own, even if they detect expiration—ensuring data consistency across the replication topology. - **RDB persistence uses a dirty-counter + timestamp trigger** (Middle): The `serverCron` function (every 100ms) checks save conditions—if `dirty` (modifications since last save) exceeds a threshold within a time window, it fires BGSAVE via a child process, avoiding the blocking behavior of the synchronous SAVE command. - **AOF persistence records every write in protocol format** (Middle): After executing a write command, Redis appends the command in RESP protocol to `aof_buf`, then handles file write and sync—enabling exact reconstruction of the dataset through command replay. ## 【Reading Tips】 - **Skim the opening chapters if you know basic data structures**: The linked-list and dictionary chapters are standard CS material; focus instead on Redis-specific twists like progressive rehash and the exact conditions for encoding upgrades. - **Deep-read the object system chapter (Ch. 8)**: This is the conceptual heart—understanding `redisObject` (type, encoding, ptr, lru) explains why commands behave polymorphically and how memory optimization actually works. Use `OBJECT ENCODING` on a live Redis to verify. - **Pay attention to the "重点回顾" (key review) sections**: Each chapter ends with a bulleted summary—these are excellent for revision and for identifying which details matter most for interviews or production debugging. - **Treat the pseudocode seriously**: The book uses Python pseudocode for complex algorithms (like `activeExpireCycle`); trace through these carefully—they reveal the actual control flow better than prose descriptions. - **Note the version context**: The book targets Redis 2.9/3.0 (2014). Core single-machine mechanics remain valid, but verify multi-machine features (Sentinel, clustering) against current documentation before relying on them in production. ## 【Coverage Limits】 This guide covers the book's single-machine internals (data structures, object system, database engine, expiration, RDB/AOF persistence) in detail. The excerpts do not cover the multi-machine chapters (replication, Sentinel, clustering), Lua scripting, transactions, or the event model—consult the full book for those. ##