Redis Network Model Analysis

Detailed analysis on the source code of redis network model

Deep dive into how Redis achieves exceptional performance through its network architecture:

Event-Driven Architecture:

Single-Threaded Event Loop:

• Main Thread: All Redis operations run in a single thread
• Non-blocking I/O: Uses epoll/kqueue for efficient I/O multiplexing
• Event Processing: Commands processed sequentially without context switching
• Atomicity: Single-threaded nature ensures atomic operations

Event Types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// File events for network I/O
#define AE_READABLE     1   // Socket ready for reading
#define AE_WRITABLE     2   // Socket ready for writing

// Time events for periodic tasks
typedef struct aeTimeEvent {
    long long id;           // Time event identifier
    long when_sec;          // When to fire (seconds)
    long when_ms;           // When to fire (milliseconds)
    aeTimeProc *timeProc;   // Time event handler
} aeTimeEvent;

Network I/O Implementation:

Client Connection Handling:

1. Accept Phase: New client connections accepted
2. Read Phase: Commands read from client sockets
3. Process Phase: Commands executed in Redis core
4. Write Phase: Responses written back to clients
5. Cleanup Phase: Closed connections handled

Buffer Management:

1
2
3
4
5
6
7

typedef struct client {
    int fd;                 // Client socket file descriptor
    sds querybuf;           // Input buffer for commands
    list *reply;            // Output buffer list
    unsigned long reply_bytes; // Bytes in output buffer
    size_t querybuf_peak;   // Peak query buffer size
} client;

Performance Optimizations:

Pipeline Support:

• Batch Processing: Multiple commands in single network round-trip
• Reduced Latency: Fewer network calls for better performance
• Buffer Reuse: Efficient memory management for pipelined requests

Memory Efficiency:

• Zero-Copy: Direct buffer manipulation where possible
• Pooled Buffers: Reuse of network buffers
• Lazy Deletion: Deferred cleanup of large objects

Redis Under the Hood

Redis: under the hood

Comprehensive exploration of Redis internal data structures and algorithms:

Core Data Structures:

String Implementation:

1
2
3
4
5

struct sdshdr {
    int len;        // String length
    int free;       // Available space
    char buf[];     // Actual string data
};

Features:

• Dynamic Sizing: Automatic growth and shrinkage
• Binary Safe: Can store any byte sequence
• Memory Efficient: Minimal overhead compared to C strings
• O(1) Length: Length stored, not calculated

Hash Table (Dict):

1
2
3
4
5
6

typedef struct dict {
    dictType *type;     // Type-specific functions
    void *privdata;     // Private data
    dictht ht[2];       // Two hash tables for rehashing
    int rehashidx;      // Rehashing progress (-1 if not rehashing)
} dict;

Rehashing Strategy:

• Incremental Rehashing: Gradual migration to avoid blocking
• Progressive: Few entries moved per operation
• Dual Tables: Old and new tables coexist during rehashing

Advanced Features:

Expiration Mechanism:

1
2
3
4
5
6

// Expiration strategies
#define EXPIRE_STRATEGY_ACTIVE    1  // Active expiration
#define EXPIRE_STRATEGY_PASSIVE   2  // Lazy expiration

// Expire dictionary tracks TTL
dict *expires;  // Maps keys to expiration times

Implementation:

• Active Expiration: Background task removes expired keys
• Passive Expiration: Keys checked on access
• Sampling: Random sampling to find expired keys efficiently

Memory Management:

• Object Encoding: Different encodings for memory efficiency
• Reference Counting: Shared objects for memory savings
• Copy-on-Write: Efficient forking for persistence

Persistence Models:

RDB (Redis Database) Snapshots:

• Fork-based: Child process handles disk I/O
• Compressed: Efficient binary format
• Point-in-time: Consistent snapshots
• Configurable: Various trigger conditions

AOF (Append Only File):

• Command Logging: Every write command logged
• Replayable: Reconstruct state by replaying commands
• Rewriting: Periodic compaction of log files
• Fsync Options: Different durability guarantees

Scaling Patterns:

Replication:

Master ──┬── Slave 1
         ├── Slave 2
         └── Slave N

Features:

• Asynchronous: Non-blocking replication
• Partial Resync: Resume from disconnection point
• Read Scaling: Distribute read load across replicas

Clustering:

Cluster Node 1 ─┬─ Hash Slots 0-5460
Cluster Node 2 ─┼─ Hash Slots 5461-10922
Cluster Node 3 ─┴─ Hash Slots 10923-16383

Implementation:

• Hash Slots: 16384 slots distributed across nodes
• Client-side Routing: Clients calculate target node
• Automatic Failover: Master failures handled automatically
• Resharding: Live migration of slots between nodes

Performance Characteristics:

Operation Complexity:

GET/SET:        O(1)
LPUSH/RPUSH:    O(1)
LRANGE:         O(S+N) where S=start, N=elements
SADD:           O(1)
SINTER:         O(N*M) where N=smallest set
ZADD:           O(log(N))
ZRANGE:         O(log(N)+M) where M=elements returned

Memory Usage:

• Overhead: ~20-30% overhead for Redis objects
• Encoding Optimization: Automatic selection of efficient encodings
• Compression: Option to trade CPU for memory savings

Production Considerations:

Configuration Tuning:

# Memory
maxmemory 2gb
maxmemory-policy allkeys-lru

# Persistence
save 900 1      # Save if 1 key changed in 900 seconds
save 300 10     # Save if 10 keys changed in 300 seconds
save 60 10000   # Save if 10000 keys changed in 60 seconds

# Network
tcp-backlog 511
timeout 0
tcp-keepalive 300

Monitoring Metrics:

• Memory Usage: Watch for memory pressure
• Command Latency: Monitor P99 latencies
• Connection Count: Track client connections
• Persistence Metrics: RDB/AOF performance
• Replication Lag: Master-slave synchronization delay

Redis’s architecture demonstrates how careful design of data structures, memory management, and I/O handling can create exceptionally high-performance systems while maintaining simplicity and reliability.