mini_redis

mini_redis is a Redis-inspired in-memory data store implemented in C++17 with a focus on clean modular design, thread safety, and operational tooling.

Features

• TCP server with blocking socket I/O and a worker thread pool
• RESP parser and serializer for Redis-compatible command framing
• Command dispatcher with PING, ECHO, SET, GET, DEL, EXISTS, EXPIRE, TTL, DBSIZE, INFO, and CONFIG GET
• Thread-safe in-memory key-value store
• TTL support with lazy reads plus active expiration sweeps
• LRU eviction when max_keys is reached
• Config file support for runtime tuning
• Structured logging with severity filtering and optional file sink
• Unit tests and a benchmark executable similar to redis-benchmark

Architecture

flowchart LR
    A["TCP Listener"] --> B["Thread Pool"]
    B --> C["Client Session"]
    C --> D["RESP Parser"]
    D --> E["Command Dispatcher"]
    E --> F["KeyValueStore"]
    F --> G["LRU List"]
    F --> H["TTL Metadata"]
    E --> I["RESP Writer"]
    I --> C
    J["Config Loader"] --> A
    J --> B
    K["Logger"] --> A
    K --> C
    L["Expiration Thread"] --> F
    M["Benchmark Tool"] --> A

Loading

Project Layout

• include/mini_redis/: public interfaces for each module
• src/: implementation of server, storage, protocol, logging, client, and config modules
• benchmark/: load generator similar to redis-benchmark
• tests/: unit test executable and lightweight test framework
• config/mini_redis.conf: sample production-style configuration

Build

cmake -S . -B build
cmake --build build
ctest --test-dir build --output-on-failure

Run The Server

./build/mini_redis_server config/mini_redis.conf

The server listens on 127.0.0.1:6379 by default.

Benchmark

./build/mini_redis_benchmark --host 127.0.0.1 --port 6379 --requests 100000 --clients 50 --pipeline 16 --command SET --data-size 64

Supported benchmark commands are SET, GET, and PING.

Configuration

Example knobs from config/mini_redis.conf:

• bind_address
• port
• worker_threads
• max_keys
• listen_backlog
• socket_read_buffer
• expiration_check_interval_ms
• log_level
• log_file

Engineering Notes

• The store is protected by a mutex because reads also update LRU state.
• Expiration is both lazy on key access and active via a periodic maintenance thread.
• Connection handling uses a bounded worker pool instead of per-request thread creation.
• The benchmark tool uses persistent connections and optional pipelining to measure throughput and latency.