Если вы хоть раз строили backend-систему, почти наверняка сталкивались с Redis. Это один из самых популярных инструментов для кэширования, очередей, rate limiting и временного хранения данных. Его используют практически везде — от стартапов до Netflix.
Но Redis появился в 2009 году. А значит он был спроектирован в эпоху, когда архитектуры серверов и подходы к параллелизму выглядели совсем иначе.
И вот теперь появляется проект Lux — новая база данных, написанная на Rust, которая обещает быть полностью совместимой с Redis, но при этом в несколько раз быстрее и в десятки раз компактнее.
Если цифры подтвердятся, это может стать одним из самых интересных инфраструктурных проектов последних лет.
Что такое Lux и почему вокруг него шум
Lux позиционируется как drop-in замена Redis.
Это важная деталь.
Она означает, что для перехода не нужно переписывать код. Достаточно поменять строку подключения — и существующие клиенты Redis будут работать как раньше.
⚙️ поддерживает стандартный протокол Redis (RESP)
⚙️ работает с любыми клиентами — ioredis, redis-py, go-redis, Jedis
⚙️ поддерживает десятки стандартных Redis-команд
На практике это означает примерно следующее:
import redis
r = redis.Redis(host="localhost", port=6379)
r.set("hello", "world")
print(r.get("hello"))
Тот же код будет работать и с Lux.
Без изменений.
И это именно тот фактор, который может резко ускорить распространение проекта.
Главная причина скорости: архитектура
Чтобы понять, почему Lux быстрее Redis, нужно посмотреть на фундаментальное отличие.
Redis исторически однопоточный.
Это сознательное решение его автора Сальваторе Санфилиппо. Однопоточность делает систему предсказуемой и избавляет от сложных блокировок.
Но у этого подхода есть предел:
один процесс = одно ядро CPU.
Lux делает противоположное.
⚙️ использует шардированную архитектуру
⚙️ распределяет данные между множеством потоков
⚙️ задействует все ядра процессора
Каждый shard — это независимый сегмент данных.
Команды распределяются между ними по хешу ключа.
Примерно так:
hash(key) → shard → выполнение команды
Такой подход масштабируется почти линейно с количеством ядер.
Где берётся прирост производительности
Lux применяет несколько технических оптимизаций, которые редко встречаются вместе.
⚙️ zero-copy парсер
Аргументы команд читаются прямо из сетевого буфера без копирования памяти.
⚙️ batch-обработка pipeline
Команды группируются по shard и выполняются пачкой.
⚙️ byte-level dispatch
Команды сопоставляются по байтам, без преобразования строк.
⚙️ lock-оптимизация
Используются быстрые RwLock из библиотеки parking_lot.
⚙️ асинхронная сеть на Tokio
Если собрать всё вместе, получается довольно агрессивная архитектура для высоких нагрузок.
Результаты бенчмарков
Сравнение проводилось с помощью redis-benchmark — стандартного инструмента тестирования.
📈 pipeline 1 — Lux примерно равен Redis
📈 pipeline 64 — уже в 3 раза быстрее
📈 pipeline 256 — 5.6 раза быстрее
На глубине pipeline 256 система достигает:
🚀 10.5 миллионов операций SET в секунду
Для кэша это огромная цифра.
И важно, что преимущество растёт с увеличением числа ядер.
Миниатюрный Docker-образ
Ещё одна неожиданная деталь — размер.
Образ Lux:
📦 около 856 КБ
Для сравнения:
📦 Redis — ~30 МБ
📦 Dragonfly — ~180 МБ
Это почти абсурдно маленький размер.
Причина проста:
⚙️ Rust компилируется в статический бинарник
⚙️ минимум зависимостей
⚙️ оптимизированный контейнер
Для edge-устройств или serverless-инфраструктуры это может оказаться критически важным.
Почему Rust всё чаще переписывает старые системы
Lux — это ещё один пример тенденции последних лет.
Старые инфраструктурные проекты переписываются на Rust.
Вот несколько известных примеров:
🦀 TiKV — распределённое KV-хранилище
🦀 Vector — система обработки логов
🦀 Cloudflare Pingora — HTTP-прокси
🦀 Meilisearch — поисковый движок
Причина довольно очевидна.
Rust позволяет получить:
⚙️ безопасность памяти без GC
⚙️ производительность уровня C++
⚙️ удобство современных языков
Для системного софта это почти идеальная комбинация.
Но сможет ли Lux заменить Redis
Вот здесь начинается самое интересное.
Redis — это не просто база.
Это целая экосистема.
📦 Redis Streams
📦 Redis Cluster
📦 Redis Sentinel
📦 огромное количество библиотек и инструментов
Lux пока поддерживает около 80 команд Redis.
Для многих сценариев этого достаточно:
⚙️ кэш
⚙️ rate limiting
⚙️ временные данные
⚙️ pub/sub
Но для сложных production-кластеров может понадобиться больше возможностей.
Мой взгляд
Честно говоря, такие проекты появляются регулярно.
Но Lux выделяется несколькими вещами.
⚙️ очень маленький код и образ
⚙️ полная совместимость с Redis
⚙️ агрессивная оптимизация производительности
Если команда продолжит развитие, Lux может занять нишу:
ультра-быстрого Redis-совместимого кэша.
Особенно в микросервисных системах.
Заключение
История Lux показывает интересный тренд.
Инфраструктурный софт начинает переживать вторую молодость.
Старые архитектурные решения пересматриваются.
Новые языки вроде Rust позволяют создавать системы:
🚀 быстрее
🚀 компактнее
🚀 безопаснее
Redis никуда не исчезнет — слишком большая экосистема.
Но такие проекты, как Lux, могут стать новым стандартом для high-performance кэшей.
И вполне возможно, что через несколько лет мы будем писать:
lux://localhost:6379
так же привычно, как сегодня пишем redis://.