Форк Valkey почти незаметен после Redis — и вот это самое «почти»

MAATRIX

Redis на сервере стоит годами, работает, и вдруг оказывается, что лицензия под ним уже не та, под которую вы его когда-то ставили. Valkey — открытый форк, появившийся в ответ на это изменение, и на первый взгляд разница незаметна: тот же протокол, те же команды, тот же redis-cli, который можно направить на valkey-server и не заметить подмены. Но «почти незаметно» — не значит «полностью прозрачно», и именно в этом «почти» прячутся модули, которых нет, версии, которые разошлись, и детали миграции, которые стоит проверить до, а не после переключения продакшена.

Почему появился Valkey и как устроено сообщество вокруг него

Redis долгие годы распространялся под пермиссивной BSD-лицензией — классическим открытым кодом без ограничений на использование, встраивание или перепродажу как услуги. В 2024 году компания, развивающая Redis, сменила лицензию на новых релизах на комбинацию source-available вариантов: код по-прежнему открыт для чтения, но условия использования перестали соответствовать формальному определению open source от OSI. Формально изменение целилось в облачных провайдеров, заворачивающих Redis в управляемую услугу без участия в разработке, но формулировки задели и куда более широкий круг пользователей.

В ответ часть сообщества и несколько крупных инфраструктурных компаний создали форк под эгидой Linux Foundation — нейтральной структуры, под которой живут многие открытые проекты. Форк стартовал с последней BSD-версии Redis и сохранил именно этот пермиссивный вариант лицензии для всего дальнейшего кода. Практически это значит: код на момент разделения — общее наследие, всё добавленное после — независимая работа двух команд, которые больше не синхронизируют изменения друг с другом.

Важная деталь для тех, кто просто ставит Redis на свой VPS и не перепродаёт его как услугу: ограничения новой лицензии Redis адресованы прежде всего тем, кто заворачивает СУБД в управляемый облачный продукт. Если вы разворачиваете Redis для собственного приложения, юридический риск для вас обычно невелик — переход на Valkey тут мотивирован предсказуемостью лицензии на годы вперёд, а не тем, что нынешняя лицензия что-то реально запрещает лично вам. Если же ваш случай — хостинг или SaaS с СУБД внутри продаваемого продукта, стоит внимательно прочитать актуальный текст лицензии или спросить юриста, а не додумывать по статье в блоге.

Что совместимо «из коробки»

Здесь хорошая новость действительно хорошая. Valkey говорит на том же бинарном протоколе RESP (RESP2 и RESP3), что и Redis, — а значит, любая клиентская библиотека, которая просто обменивается RESP-командами по TCP, работает с Valkey без единой правки кода: redis-py, ioredis, node-redis, Jedis, Lettuce, любой ORM с адаптером под Redis видит valkey-server как обычный Redis-инстанс, потому что с точки зрения провода это он и есть.

Подавляющее большинство команд унаследовано без изменений: строки, хэши, списки, множества, отсортированные множества, стримы, pub/sub, транзакции MULTI/EXEC, скрипты на Lua через EVAL. Формат конфигурационного файла тоже совместим — redis.conf, который вы годами правили руками, читается valkey-server практически один в один, включая maxmemory, maxmemory-policy, appendonly, save. Команда PING через redis-cli, направленный на valkey-server, вернёт PONG точно так же, и для повседневных операций разница действительно не ощущается.

Формат данных на диске — тоже общее наследие: RDB-снапшоты и AOF-журнал, записанные Redis на момент разделения кодовых баз, читаются Valkey без конвертации. Механизм fork() и copy-on-write, лежащий в основе BGSAVE и не блокирующий сервис во время сохранения, подробно разобран в статье про снапшот Redis — Valkey использует ровно тот же приём, потому что унаследовал этот код целиком.

Где совместимость даёт трещину

Первая и самая ощутимая дыра — модули. Расширения вроде поиска по JSON-документам, полнотекстового поиска, временных рядов и вероятностных структур данных распространялись отдельно, под собственными условиями лицензирования, и в форк не перешли — у Valkey свой API для модулей и отдельная, гораздо более молодая экосистема community-реализаций аналогичной функциональности. Если приложение реально дёргает команды вида JSON.SET, FT.SEARCH, TS.ADD или BF.ADD — это не «почти совместимо», это отдельная зависимость без готового бинарного эквивалента с тем же уровнем зрелости. Прежде чем что-то переключать, стоит погрепать код на команды с точкой в названии — это обычно и есть модульные команды, а не команды базового движка.

Вторая трещина — возможности, добавленные в Redis уже после разделения кодовых баз. Обе ветки развиваются независимо: там, где Redis Inc добавляет фичу первой, Valkey реализует её позже и немного иначе или не реализует вовсе, если она завязана на закрытые части экосистемы. Обратное тоже верно — у Valkey появляются свои возможности, которых нет в Redis. Надёжный способ убедиться, что нужная команда есть именно в вашей версии, — свериться с документацией этой версии, а не полагаться на память о том, «как было в Redis».

Третья деталь — то, что возвращает INFO в поле с версией сервера. Часть библиотек и систем мониторинга парсит эту строку, чтобы понять, какие возможности доступны, и включает или выключает логику по её значению. Если ваш стек так устроен, стоит прогнать его на тестовом Valkey-инстансе и проверить, не ломается ли определение фич из-за непривычного формата версии, прежде чем доверять этому в проде.

Четвёртая деталь касается кластеров и репликации: протокол был общим на момент форка, но с тех пор развивался в двух местах отдельно, и официальной гарантии, что нода Redis сможет быть репликой ноды Valkey (или наоборот) на актуальных версиях, нет. Относитесь к смешиванию Redis и Valkey в одной группе репликации или кластере как к эксперименту для стенда, а не как к штатной возможности. Если у вас уже есть кластер на Redis, устройство шардирования по хэш-слотам и минимальная топология разобраны в статье про настройку Redis Cluster — почти всё это знание переносится на Valkey Cluster один в один, кроме момента смешивания разных продуктов в одной живой топологии.

Производительность: что реально можно сравнивать

Конкретных цифр «Valkey быстрее или медленнее Redis на N процентов» здесь не будет, и такой цифре из чужого блога стоит не доверять без собственной проверки — обе стороны заинтересованы показать себя выгоднее на удобно подобранном бенчмарке.

Что можно сказать предметно. На момент форка движок был файл в файл один и тот же: та же однопоточная модель обработки команд в основном цикле событий, те же структуры данных внутри — хэш-таблицы, skiplist для отсортированных множеств, listpack для компактных коллекций. Базовая производительность типовых операций на момент разделения была идентична просто потому, что это был один код. С тех пор оба проекта независимо занимаются оптимизацией, в частности многопоточной обработкой ввода-вывода поверх однопоточного выполнения самих команд. Куда именно сместился баланс к моменту, когда вы читаете статью, зависит от конкретных версий обоих продуктов — и это тот случай, когда надёжный ответ только один: замерить самостоятельно.

Практический план: разверните обе СУБД рядом на одинаковом железе, прогоните redis-benchmark (он работает против обоих серверов без изменений — снова благодаря общему протоколу) с профилем нагрузки, похожим на реальный: размер значений, соотношение чтения и записи, число соединений. Микробенчмарк на пустых SET/GET в одно соединение почти никогда не отражает то, что происходит под нагрузкой продакшена с пайплайнингом, большими хэшами или активным pub/sub.

Миграция в проде: пошагово

Первый шаг — не технический, а инвентаризационный. Пройдитесь по коду и конфигурации мониторинга в поисках команд модулей (всё с точкой в имени — JSON., FT., TS., BF., CF.) и мест, где логика завязана на строку версии из INFO. Если модулей нет — миграция технически простая. Если есть — это отдельный проект с оценкой зрелости модульной экосистемы Valkey под вашу задачу, а не быстрая замена бинарника.

Дальше — сама замена:

# останавливаем текущий Redis
sudo systemctl stop redis-server

# ставим Valkey из пакетов дистрибутива или официального
# репозитория проекта — сверьтесь с документацией valkey.io под вашу ОС

# конфиг копируется как есть — большинство директив совпадает
sudo cp /etc/redis/redis.conf /etc/valkey/valkey.conf

# RDB-снапшот переносится без конвертации
sudo cp /var/lib/redis/dump.rdb /var/lib/valkey/dump.rdb

sudo systemctl start valkey-server

После старта проверьте лог сервиса на строки вида «unsupported directive» — часть опций, добавленных в Redis уже после форка, valkey-server может не знать и либо проигнорировать, либо отказаться стартовать со старым конфигом. Затем базовая проверка живости:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO server | head -20

Для одиночного инстанса с допустимым коротким окном обслуживания схема «остановили — скопировали — запустили» самая простая и предсказуемая. Для сервиса без допустимого даунтайма соблазн настроить Valkey как живую реплику работающего Redis-мастера понятен, но, как отмечено выше, официальной гарантии кросс-совместимости репликации между продуктами на произвольных версиях нет — проверяйте такой путь на копии продакшен-нагрузки в стейджинге, а не сразу на боевом мастере. Более консервативный вариант для нулевого даунтайма — двойная запись на уровне приложения на переходный период, прогрев Valkey реальным трафиком чтения, сверка ответов и только затем переключение точки записи.

Отдельно держите план отката на случай, если после переключения что-то пойдёт не так, — общие принципы такого плана разобраны в статье про план отката миграции; применительно к Valkey это прежде всего означает не удалять старый redis-server и его данные, пока новый инстанс не отработал под реальной нагрузкой хотя бы несколько дней.

Кому переходить сейчас, а кому подождать

Переход оправдан прямо сейчас, если вы используете Redis как классическое хранилище структур данных — строки, хэши, списки, множества, отсортированные множества, очереди на стримах, pub/sub — без модулей Redis Stack, работаете со стандартными клиентскими библиотеками и хотите однозначной, предсказуемой на годы вперёд открытой лицензии под тем, что развёрнуто на сервере. Для типовых сценариев — кэш перед базой, хранилище сессий, брокер простых очередей, счётчики и рейтинги — миграция действительно близка к замене бинарника, и откладывать её нет особого смысла, если лицензионная предсказуемость для вас важна как принцип.

Стоит повременить или как минимум тщательно проверить на стенде, если вы плотно завязаны на модули Redis Stack — полнотекстовый поиск, JSON-документы, временные ряды, вероятностные структуры — и экосистема аналогов под Valkey ещё не закрывает вашу задачу с нужной полнотой; если критично получать самые свежие возможности сразу по мере их выхода именно в Redis; либо если мониторинг, ORM или инфраструктурный код настолько глубоко полагается на конкретную строку версии или специфичное поведение недавних релизов Redis, что требует отдельного тестового цикла прежде, чем доверять этому прод.

И отдельно стоит трезво взвесить исходный мотив. Если вы просто разворачиваете СУБД для собственного приложения на своём сервере, а не продаёте её как отдельную услугу третьим лицам, лицензия Redis сама по себе вряд ли создаёт реальные юридические ограничения, и переход на Valkey тут — решение о предсказуемости и независимости от одного вендора на годы вперёд, а не срочная необходимость. Решение не нужно принимать необратимо и мгновенно: можно спокойно поднять Valkey рядом на тестовом стенде, прогнать через него часть нагрузки и решить на основе собственных данных, а не чужих утверждений о том, что «всё то же самое».

Частые вопросы