Проект Valkey, форк Redis, появился после смены лицензии Redis в марте 2024 года и сохраняет обратную совместимость с Redis 7.2. Это key-value база данных, которая хранит данные в оперативной памяти и используется там, где критичны низкая задержка и быстрый доступ. Основные сценарии — кеширование, очереди, распределённые блокировки, координация микросервисов. С версии 9.1 добавлены гранулярное управление доступом, новые атомарные операции и улучшена производительность. Материал подготовлен на основе вебинара «Valkey. Инструкция по применению» и охватывает три практических примера: кеш для «1С-Битрикс», распределённые блокировки для 1С и использование Valkey-Search в RAG-сценарии для ИИ-агента.
**Что нового в версии 9.1**
Версия 9.1 развивает совместимость с Redis 7.2 и добавляет функции, которые ранее были недоступны. Появились списки контроля доступа (ACL) на уровне базы данных: теперь можно ограничить пользователя конкретной БД внутри экземпляра. Добавлены атомарные команды для работы с хешами и ключами — например, получить и удалить значение за одну операцию или установить значение вместе со сроком жизни. Для кластерного режима стала доступна команда сканирования всего ключевого пространства одной инструкцией, раньше каждую ноду приходилось обходить отдельно.
Lua-движок вынесен в модуль, что в Yandex Cloud позволило повысить производительность до двух раз в отдельных сценариях. Для данных размером до 128 байт эффективность использования памяти выросла до 30% за счёт оптимизации внутреннего хранения. Улучшен механизм Copy Avoidance, снижающий количество копирований при отправке данных клиенту, и уменьшены задержки при рехешировании хеш-таблицы. В области наблюдаемости появились метрики загрузки основного потока, JSON-логи, контроль срока действия TLS-сертификатов и метрики объёма трафика между нодами кластера. В кластерные команды добавлена информация о зонах доступности для более точной маршрутизации запросов.
**Когда выбирать Valkey, а когда — другую систему**
Valkey оправдан, когда нужен максимально быстрый доступ к данным, которые помещаются в оперативную память (гигабайты или сотни гигабайт; хранить терабайты таким способом дорого). Основные случаи применения: кеш перед основной БД, очереди и Pub/Sub, распределённые блокировки, хранение промежуточных результатов вычислений. Встроенный модуль Valkey-Search добавляет векторный поиск для ИИ-сценариев.
Не подходит для тяжёлой аналитики по большим объёмам, сложных транзакций с высокой связностью данных и в качестве единственного хранилища критически важной информации. Из-за асинхронной репликации и задержки персистентности при отказе мастера возможна потеря последних изменений. Поэтому для незаменимых данных (например, финансовых записей) Valkey стоит использовать как вспомогательный слой, а не основную базу.
**Как создать кластер в Yandex Managed Service for Valkey**
Во всех трёх сценариях применялась похожая базовая конфигурация. В консоли выбирается версия 9.1, при необходимости включается использование FQDN вместо IP-адресов. Настраивается персистентность: для кеша её включают только на репликах. Задаётся пароль, распределение хостов по зонам доступности, для кеша — политика вытеснения ключей. Оставляется доступ из Yandex WebSQL для проверки ключей. Более детальная последовательность описана в инструкции по созданию кластера.
**Сценарий № 1: Valkey как кеш для «1С-Битрикс»**
На виртуальной машине развёрнут готовый образ «1С-Битрикс» из Yandex Cloud Marketplace. Создан кластер Valkey с версией 9.1, FQDN, персистентностью на репликах и политикой вытеснения ключей. В настройки «1С-Битрикс» добавлен отдельный файл дополнительных параметров, где в качестве типа кеша указан Redis и передан адрес кластера Valkey. Благодаря совместимости с Redis 7.2 приложение подключается к Valkey без изменения логики. Проверить интеграцию можно через панель производительности «1С-Битрикс», мониторинг Yandex Managed Service for Valkey или через WebSQL. В результате кеш начинает работать без переработки приложения.
**Сценарий № 2: распределённые блокировки для 1С**
Valkey координирует работу нескольких клиентов 1С, чтобы они не редактировали один элемент справочника одновременно. Поскольку прямого коннектора к Valkey в демонстрационной конфигурации нет, между 1С и кластером размещён HTTP-сервис. Он предоставляет методы получения, освобождения и продления блокировки. Для получения блокировки выполняется команда SET с условием NX и сроком жизни (TTL). Экспирация защищает от ситуации, когда клиент аварийно завершил работу, а блокировка осталась. Освобождение и продление реализованы Lua-скриптом через EVAL: скрипт атомарно проверяет токен и удаляет или обновляет TTL только у владельца. В модуле 1С через HTTP-запросы клиент получает блокировку при открытии формы, продлевает каждые 30 секунд и освобождает при закрытии. Это переносит координацию из прикладной базы в быстрое централизованное хранилище.
**Сценарий № 3: Valkey-Search и RAG для ИИ-агента**
Архитектура: данные приложения → Valkey-Search → RAG → MCP → ИИ-агент → модель в Yandex AI Studio. При создании кластера подключается модуль Valkey-Search, доступна настройка количества потоков чтения и записи. Данные загружаются в Valkey и индексируются. ИИ-агент через MCP обращается к поисковому компоненту, получает найденные записи и формирует ответ с помощью модели из Yandex AI Studio. Запросы успешно отрабатывают на разных языках. Valkey-Search выступает быстрым поисковым слоем, а найденный контекст используется моделью для ответа.
**Чек-лист перед использованием Valkey**
Перед внедрением стоит оценить несколько аспектов: действительно ли приложению нужен минимальный отклик (иначе хранение в RAM может быть избыточно дорогим); допустима ли потеря части данных при отказе (для кеша — да, для реестра транзакций — нет); какой объём данных будет храниться (от этого зависит стоимость и архитектура); как приложение переживёт отказ мастера; какая политика вытеснения ключей будет использоваться; какие метрики отслеживать (загрузка потока, использование памяти, количество клиентов, сетевой трафик).
**Ограничения и важные замечания**
Valkey не стоит рассматривать как единственное хранилище критически важных данных из-за асинхронной репликации. Если мастер выходит из строя до того, как изменения записаны на диск или переданы на реплику, последние операции теряются. Поэтому для незаменимых транзакций лучше использовать специализированную основную базу данных, а Valkey применять как кеш или вспомогательный слой.
**Заключение**
Valkey подходит для задач, где важна скорость доступа: кеширование, координация сервисов, поиск контекста для ИИ-агентов. Версия 9.1 принесла улучшения в управлении доступом, производительности и наблюдаемости. При проектировании решения надо учитывать объём оперативной памяти, политику вытеснения ключей и риск потери последних изменений при сбоях. Представленные сценарии демонстрируют, как Valkey может быть встроен в существующие системы без глубокой переработки прикладной логики.
Источник: https://yandex.cloud/ru/blog/valkey-cache-locks-rag
Комментарии(0)
Оставьте комментарий
Войдите, чтобы присоединиться к обсуждению