Redis EVAL原子性、键TTL及架构与垃圾回收相关技术问询

Hey there! Let's break down your Redis questions one by one, since they touch on some core, often misunderstood mechanics of how Redis operates:

1. Atomicity of EVAL for keys with TTL #

First off, Lua scripts executed via EVAL are fully atomic in Redis—regardless of whether the keys involved have a TTL or not. Here's why:

• Redis runs all command execution (including Lua scripts) in a single main thread. When a script starts running, Redis won't process any other client commands until the script finishes. This means every operation in your script—whether it's reading a key's TTL, updating its value, or adjusting the TTL itself—happens as an uninterrupted unit.
• Even if your script combines multiple operations on a TTL-enabled key (like checking the remaining TTL with TTL then modifying the value with SET), there's no window for another client to alter that key in between. The entire script is treated as one logical command, so atomicity is guaranteed just like any built-in Redis command.

2. Redis' overall architecture (beyond the single-threaded client view) #

You're right that from a client's perspective, Redis feels like a single-threaded system—and that's because the core command execution layer is single-threaded. But Redis' full architecture includes several complementary components to handle non-critical work without blocking the main thread:

• Main thread: This is where all client commands, Lua script execution, and key-space operations happen. It's the "brain" that processes your actual data requests.
• Background threads: Introduced in earlier versions and expanded over time, these handle tasks that don't need immediate access to the main data set. Examples include:
  • Writing RDB snapshots to disk
  • Rewriting the AOF log
  • Asynchronous deletion operations (UNLINK, FLUSHDB ASYNC)
  • Cleaning up timed-out client connections
• Network I/O multi-threading (Redis 6.0+): To tackle high-concurrency bottlenecks, Redis added multi-threaded handling for network read/write operations. The main thread still processes the actual commands, but offloading socket I/O to separate threads boosts throughput without breaking the single-threaded command execution model.

In short: The single-threaded part is the command execution pipeline, but the overall architecture uses auxiliary threads to handle heavy, non-blocking work.

3. GC, key eviction, and task scheduling during Lua script runs #

Let's unpack this into parts:

Garbage Collection (GC) #

Redis uses an incremental garbage collector that runs in the main thread, but it's designed to avoid long pauses. When a Lua script is executing, Redis will not trigger any GC cycles. The GC only runs in gaps between client commands or during idle periods—never in the middle of a script execution. This ensures your script runs uninterrupted.

Key Eviction #

If Redis hits its maxmemory limit and needs to evict keys to free up space, this eviction logic runs in the main thread. However, eviction will not happen while a Lua script is running. Redis waits until the script completes before evaluating whether eviction is necessary. This protects the atomicity of your script—you don't have to worry about a key being evicted mid-script, which would break your logic.

Internal vs. User Task Scheduling #

User tasks (client commands, Lua scripts) take priority in the main thread. Internal tasks like incremental GC, key eviction checks, or even some housekeeping work are only executed when the main thread is idle or between user commands.

• Background thread tasks (like RDB writes) run independently of the main thread, so they don't interfere with script execution at all.
• Main-thread internal tasks are paused entirely while a Lua script is running—they'll resume once the script finishes and the main thread is free again.

内容的提问来源于stack exchange，提问作者Silk0vsky