В 2026 году вопрос Redis vs KeyDB vs DragonflyDB звучит уже не как спор фанатов бенчмарков, а как обычная эксплуатационная задача: какой self-hosted cache поставить на VDS, чтобы приложение стало быстрее, а поддержка не превратилась в отдельный проект. У вебмастера это может быть object cache для WordPress или Laravel. У DevOps — сессии, rate limit, очереди, короткоживущие токены, кэш профилей и API-ответов.
Сразу обозначу позицию. Redis остаётся самым предсказуемым выбором по экосистеме, клиентским библиотекам и документации. KeyDB интересен там, где нужна Redis-совместимость с многопоточностью и отдельными режимами репликации, но к его актуальности и темпу развития стоит относиться внимательно. DragonflyDB выглядит сильным претендентом на роль быстрого Redis-compatible сервера для больших нагрузок на одном узле, но требует проверки именно с вашим приложением.
В этой статье я не буду устраивать гонку за миллионами операций в секунду. На реальном VDS важнее другое: сколько памяти съедает процесс с вашими ключами, как он ведёт себя при истечении TTL, насколько спокойно переживает restart, умеет ли работать с вашими клиентами и не создаёт ли хвост задержек на p95 и p99.
Коротко: кто есть кто
Redis — классическая in-memory database и кэш, с которой совместимы почти все фреймворки, CMS, очереди и библиотеки. Для PHP, Node.js, Python, Go, Ruby и Java есть зрелые клиенты, готовые настройки, exporters и понятные runbook-практики. Вокруг лицензирования Redis в 2024–2025 годах было много шума, а Redis 8 вернулся к открытой модели AGPLv3. На практике это означает: перед внедрением всё равно проверяйте лицензию конкретной версии и требования вашей компании, но технически Redis остаётся базовой точкой отсчёта.
KeyDB — форк Redis, который сделал ставку на многопоточность, совместимость протокола и дополнительные возможности вроде active-replica сценариев. Идея привлекательная: взять привычный API и лучше использовать несколько vCPU. Но для новых проектов в 2026 году я бы смотрел не только на скорость, а на активность релизов, доступность пакетов для вашей ОС, совместимость команд и поддержку со стороны инструментов мониторинга.
DragonflyDB — современный сервер, совместимый с Redis-протоколом для большого набора команд. Его архитектура рассчитана на эффективную работу на многоядерных машинах: меньше конкуренции за блокировки, хорошее использование CPU, высокая пропускная способность. Для cache on VDS это звучит заманчиво, особенно если один Redis-процесс упирается в одно ядро. Но Redis-compatible не равно полная идентичность: Lua, streams, pub/sub, модули, большие ключи и персистентность нужно проверять отдельно.
Если нужен максимально безопасный выбор без экспериментов — начинайте с Redis. Если упёрлись в CPU одного процесса — тестируйте DragonflyDB. Если уже используете KeyDB и довольны поведением — не мигрируйте только ради моды.
Что важнее на VDS: CPU, RAM, latency или совместимость
У кэша на VDS есть своя специфика. Вы не управляете физическим сервером целиком, но отвечаете за лимиты памяти, настройки ядра, диск, обновления и сетевые задержки. Поэтому выбор движка нужно начинать не с рекламных throughput-цифр, а с профиля нагрузки.
Для сайта на PHP и CMS чаще всего важны низкие задержки на небольших значениях: тысячи и десятки тысяч коротких ключей, TTL от минут до суток, операции GET, SET, DEL, INCR, иногда списки и хэши. Здесь Redis почти всегда достаточен. Узким местом чаще становится не сам Redis, а неправильный maxmemory, отсутствие eviction-политики, сетевой round-trip между приложением и кэшем или блокировки сессий.
Для API, маркетплейса, realtime-дашборда или сервиса с активными очередями нагрузка другая: много параллельных соединений, burst-трафик, массовые истечения TTL, большие хэши, sorted sets, pub/sub и streams. Тут уже интересно сравнивать Redis, KeyDB и DragonflyDB под конкретные команды. Один движок может быть быстрее на простом GET, но хуже вести себя на ZADD, SCAN или при сохранении снимка.
RAM — главный бюджет self-hosted cache. In-memory database хранит данные в памяти, а значит нужно закладывать не только размер значений, но и накладные расходы на ключи, структуры данных, фрагментацию, клиентские буферы, репликацию и fork при сохранении. Ошибка новичка — выделить кэшу всю свободную память VDS. При пике приложение, база данных и сам демон кэша начинают конкурировать за RAM, Linux включает reclaim, latency растёт, а затем приходит OOM killer.
Практичный подход: задавайте явный maxmemory, оставляйте запас под ОС и приложение, включайте понятную eviction-политику и мониторьте не только used memory, но и eviction, hit ratio, latency, rejected connections и blocked clients. Без этих метрик сравнение Redis, KeyDB и DragonflyDB превращается в гадание.
Совместимость: почему Redis-compatible нужно проверять руками
Фраза Redis-compatible обычно означает совместимость с протоколом RESP и большим набором команд Redis. Для простого кэша этого часто достаточно: приложение открывает TCP-соединение, отправляет команды, получает ответы. Но в продакшене всплывают детали.
Во-первых, не все приложения используют только базовые команды. Laravel, Symfony, Django, Celery, BullMQ, Sidekiq, WordPress-плагины и собственные библиотеки могут полагаться на Lua-скрипты, pipeline, transactions, streams, pub/sub, blocking-команды или специфическое поведение TTL. Иногда отличие проявляется не сразу, а под нагрузкой: например, при массовой обработке очереди или очистке namespace.
Во-вторых, есть модули. Redis-модули, полнотекстовый поиск, bloom-фильтры, JSON-структуры и time series — это уже не просто кэш. Если приложение зависит от модулей Redis, KeyDB или DragonflyDB нельзя считать drop-in заменой без отдельной проверки. Можно выиграть CPU, но получить несовместимость в редко используемом участке кода.
В-третьих, важны клиентские библиотеки. Некоторые клиенты вызывают INFO, ожидают конкретные поля, поддерживают Sentinel, Cluster, TLS, ACL или RESP3. Если библиотека написана с предположением, что на другой стороне именно Redis, совместимый сервер может отлично работать на базовых командах и ломаться в healthcheck или failover.
Минимальный тест совместимости перед миграцией: снимите список используемых команд, прогоните интеграционные тесты приложения, повторите типовые фоновые задачи, проверьте reconnect, restart сервера, blocking-команды, Lua-скрипты и поведение клиента при таймаутах. Это несложно, но экономит много ночных разборов.
Производительность: где Redis проигрывает, а где всё ещё хорош
Redis исторически однопоточен для исполнения команд, хотя вокруг него есть I/O threads и множество оптимизаций. На небольшом VDS это часто плюс: поведение простое, задержки предсказуемые, диагностировать легче. Один процесс Redis на 1–2 vCPU может обслуживать типовой сайт быстрее, чем нужно. Если hit ratio высокий, значения маленькие, а приложение живёт на том же сервере через localhost, выигрыш от смены движка может быть незаметен.
Проблемы начинаются, когда одно ядро становится потолком. В мониторинге это выглядит так: один CPU занят почти на 100%, остальные простаивают, latency spikes растут, команды копятся, а сеть и диск не являются узким местом. В этом месте есть три пути: разделить кэш по нескольким Redis-инстансам, перейти к кластерной схеме или тестировать многопоточные альтернативы вроде KeyDB и DragonflyDB.
KeyDB может лучше использовать несколько потоков в части сценариев. Это полезно на VDS с 4–8 vCPU, когда нагрузка хорошо параллелится и не упирается в один горячий ключ. Но линейного прироста ждать не стоит: если постоянно обновляется один счётчик, один большой sorted set или одна очередь с жёстким порядком, многопоточность не снимет всю проблему.
DragonflyDB интересен тем, что изначально проектировался под многоядерность и высокую эффективность памяти. В ряде workloads он показывает сильную пропускную способность и хорошие задержки на больших количествах соединений. Но администратору важно не только среднее значение latency, а p95, p99 и поведение при фоновых операциях. На VDS именно хвост задержек часто портит пользовательский опыт.
Если хотите честный тест, не запускайте один только redis-benchmark с идеальными маленькими ключами. Сгенерируйте профиль, похожий на ваш: доля чтения и записи, размер ключей, размер значений, TTL, pipeline, количество клиентов, периодические удаления, фоновые сохранения, реальные команды приложения. Потом сравните ops/sec, RSS, CPU steal, p99 latency, eviction и время восстановления после restart.
Россия
Нидерланды
Память и eviction: самый частый источник сюрпризов
Кэш должен уметь забывать. Если кэш не забывает, он рано или поздно превращается в причину аварии. Для Redis и совместимых серверов первым делом задают maxmemory. Дальше выбирают maxmemory-policy: например, allkeys-lru, allkeys-lfu, volatile-lru или noeviction. Для обычного object cache чаще подходят политики, которые могут вытеснять любые ключи. Для сессий и критичных токенов всё сложнее: потеря ключа может быть видимой для пользователя.
Redis хорошо изучен в плане фрагментации памяти и поведения allocator. Команды INFO memory, MEMORY STATS и MEMORY USAGE помогают быстро понять, куда ушла RAM. DragonflyDB в некоторых сценариях может быть экономнее, но проверять нужно на ваших структурах данных. KeyDB близок к Redis по модели, но фактическое потребление зависит от версии, настроек и нагрузки.
На маленьком VDS особенно опасны большие ключи. Один JSON на несколько мегабайт, огромный hash, список или set могут испортить latency сильнее, чем миллион маленьких ключей. Команды, которые работают с большим объектом целиком, нагружают сервер дольше. Поэтому хорошая практика — ограничивать размер значений на уровне приложения, задавать TTL везде, где это возможно, и регулярно искать hot keys.
Не забывайте про swap. Для in-memory database swap почти всегда вреден: лучше получить контролируемое вытеснение по maxmemory, чем секунды задержки из-за подкачки. На VDS можно иметь небольшой swap или zram для выживания системы, но сам кэш не должен активно свопиться. Если видите рост swap-in и swap-out при нагрузке, это сигнал пересмотреть лимиты памяти.
Персистентность: нужен ли диск кэшу
Для чистого cache on VDS персистентность иногда можно отключить: при restart приложение прогреет кэш заново. Это упрощает эксплуатацию и снижает нагрузку на диск. Но не всякий Redis используется только как кэш. Часто в нём лежат сессии, rate limit counters, очереди, отложенные задачи, idempotency keys и временные бизнес-состояния. Потеря таких данных может быть терпимой, а может стать инцидентом.
Redis предлагает RDB-снимки, AOF-журнал и гибридные режимы. RDB быстрее восстанавливается и проще, но даёт больший риск потери последних изменений. AOF снижает риск потери данных, но сильнее зависит от диска и настроек fsync. На VDS с ограниченными IOPS неправильно настроенный AOF может добавить заметные задержки. Параметры appendonly, appendfsync и расписание snapshot нужно выбирать по RPO, а не по привычке.
У DragonflyDB и KeyDB есть свои механики сохранения и совместимости с форматами. Перед миграцией проверьте, как делается snapshot, сколько сервер стартует с вашим объёмом данных, что происходит при заполнении диска и есть ли понятный restore-план. В продакшене важен не факт наличия персистентности, а проверенная процедура восстановления.
Мой практический совет: если данные можно восстановить из основной базы, не усложняйте кэш. Если данные нельзя потерять, честно спросите себя, не используете ли вы кэш как primary database. Redis и совместимые решения умеют больше, чем просто кэш, но требования к бэкапам, репликации и мониторингу тогда становятся как у настоящей базы данных.
Репликация, Sentinel, Cluster и одиночный VDS
На одном VDS высокая доступность ограничена физикой: если узел недоступен, локальный кэш тоже недоступен. Поэтому для небольших проектов нормально начинать с одного инстанса и делать приложение устойчивым к временной потере кэша. Это означает короткие timeouts, fallback на базу данных, отсутствие жёсткой зависимости от кэша при рендеринге страниц и аккуратные retry.
Redis Sentinel нужен, когда есть несколько узлов и требуется автоматическое переключение master. Redis Cluster нужен для шардинга и горизонтального роста, но он добавляет сложность: hash slots, redirect, совместимость клиентов, миграция ключей, ограничения multi-key операций. Для большинства VDS-проектов Cluster — это не первый шаг, а ответ на реальный потолок одного узла.
KeyDB известен active-replica возможностями, но такие схемы надо проектировать осторожно. Active-active звучит красиво, пока не появляются конфликтующие записи, порядок операций и ожидания приложения. Для кэша это иногда приемлемо, для очередей и счётчиков — далеко не всегда.
DragonflyDB развивает репликацию и совместимость, но при выборе на 2026 год нужно смотреть конкретную стабильную версию и требования приложения. Если у вас простая схема master-replica для read scaling или failover, проведите отдельный тест переключения: остановите master, посмотрите время reconnect, проверьте потерю записей и поведение клиентов.
Безопасность: не выставляйте кэш в интернет
Redis, KeyDB и DragonflyDB не должны быть публичной точкой входа для всего интернета. Это внутренний сервис. На VDS безопасная базовая схема проста: bind на localhost или приватный интерфейс, firewall, отдельный пользователь ОС, ACL или пароль, минимум прав, закрытый порт снаружи. Если кэш нужен нескольким серверам, лучше соединять их по приватной сети или защищённому туннелю, а не открывать порт всем адресам.
Для Redis важно настроить protected-mode, bind, requirepass или ACL-пользователей. Не давайте приложению пользователя, который может выполнять все команды, если ему нужны только чтение и запись в свой namespace. Команды администрирования, flush и config должны быть недоступны обычному клиенту.
TLS может понадобиться, если трафик идёт между узлами по недоверенной сети. Но TLS добавляет CPU overhead и усложняет диагностику. На одном VDS через loopback он обычно не нужен. Между серверами — смотрите по модели угроз, требованиям компании и возможностям клиента. Главное — не заменять firewall одним только паролем.
Мониторинг: какие метрики смотреть до смены движка
Перед миграцией с Redis на KeyDB или DragonflyDB соберите базовую картину. Без неё вы не поймёте, стало лучше или просто изменились симптомы. Минимум: CPU по ядрам, RSS процесса, used_memory, mem_fragmentation_ratio или аналог, количество команд в секунду, hit ratio, eviction, expired keys, blocked clients, connected clients, network in/out и latency percentiles.
Для Redis полезны INFO, SLOWLOG GET, LATENCY DOCTOR, sampling hot keys и метрики exporter. Для совместимых серверов часть команд может поддерживаться полностью, часть — частично, поэтому проверяйте, что dashboards действительно показывают правду, а не пустые поля.
Отдельно смотрите метрики VDS: CPU steal, iowait, PSI memory pressure, swap, ошибки сети, лимиты файловых дескрипторов. Иногда Redis обвиняют в задержках, хотя причина в диске, переполненной таблице conntrack, агрессивном backup job или соседнем процессе, который съел page cache. Хороший мониторинг помогает не менять двигатель, когда надо заменить шины.
Практические сценарии выбора
Небольшой сайт, WordPress, Laravel или Symfony
Берите Redis. Он проще, лучше документирован, поддерживается плагинами и фреймворками из коробки. Настройте maxmemory, TTL, eviction, socket или localhost TCP, мониторинг и systemd restart policy. Если сайт живёт на том же VDS, задержка будет минимальной, а эксплуатационные риски — ниже. Если вы выбираете между Redis и Memcached для PHP-проекта, полезно отдельно посмотреть разбор Memcached и Redis для PHP-кэша.
API с высокой долей чтения и большим числом соединений
Начните с Redis как baseline, затем протестируйте DragonflyDB на копии нагрузки. Если p99 latency и CPU заметно лучше, а совместимость подтверждена интеграционными тестами, DragonflyDB может быть отличным выбором. Особенно если вы хотите лучше использовать 4–8 vCPU на одном VDS и не готовы сразу строить Cluster.
Очереди и фоновые задачи
Будьте осторожнее. Очереди зависят от порядка, blocking-команд, ack-механики, Lua-скриптов и поведения клиента при reconnect. Redis здесь проверен годами. DragonflyDB и KeyDB нужно тестировать именно с вашей библиотекой очередей, а не только простыми командами. Для критичных задач подумайте, не нужен ли специализированный брокер сообщений.
Кэш с очень большим количеством ключей и TTL
Здесь DragonflyDB может оказаться интересным кандидатом, но решают детали: как сервер удаляет истёкшие ключи, насколько ровный latency under expiration storm, как растёт память при churn, сколько CPU тратится на housekeeping. Redis тоже умеет жить с миллионами ключей, но требует аккуратного hz, eviction и контроля hot keys. Если часть кэша живёт на уровне веб-сервера, пригодится материал про TTL-кэширование и secure link в Nginx.
Проект уже на KeyDB
Если всё стабильно, метрики здоровые, backup и restore проверены, а команда понимает эксплуатацию — не обязательно срочно мигрировать. Но для планирования на 2026 год проверьте активность проекта, доступность пакетов для вашей ОС, совместимость с клиентами и дорожную карту. Самая неприятная миграция — та, которую приходится делать в пожарном режиме из-за устаревшей зависимости.
Как тестировать на VDS без самообмана
Хороший тест начинается с одинаковых условий. Один и тот же VDS-план, одна ОС, одинаковые лимиты nofile, одинаковая сеть, одинаковый dataset, одинаковая нагрузка. Если Redis тестируется с persistence off, а DragonflyDB с включённым snapshot, результат нельзя сравнивать честно. Если один сервер прогрет, а другой только стартовал, тоже нельзя.
Не гонитесь за максимальным числом клиентов. Сначала измерьте рабочий сценарий: например, 100–500 параллельных соединений, значения по 1–4 КБ, TTL 5–60 минут, доля чтения 80–95%, периодические записи. Потом добавьте стресс: больше клиентов, большие значения, массовое истечение TTL, restart, сохранение snapshot. Вас интересует не только пик, но и деградация.
В тесте обязательно измеряйте приложение, а не только кэш. Бывает, движок стал быстрее на 30%, но TTFB сайта не изменился, потому что узкое место в MySQL, PHP-FPM или внешнем API. В таком случае миграция не окупится. А бывает наоборот: p99 ответа API улучшается из-за меньших хвостов latency, хотя средний ops/sec почти одинаковый.
После выбора зафиксируйте runbook: как обновлять, как откатывать, где конфиг, как смотреть slowlog, как менять maxmemory, что делать при OOM, как проверить backup, какие alerts критичны. Кэш кажется простым до первого инцидента, а затем выясняется, что именно он держит половину пользовательского пути.
Итоговая рекомендация на 2026 год
Если нужен универсальный, понятный и максимально совместимый self-hosted cache на VDS — выбирайте Redis. Он остаётся стандартом, вокруг него зрелая экосистема, а большинство проблем уже кто-то решал до вас. Для малого и среднего веб-проекта это обычно лучший баланс риска и пользы.
Если Redis упирается в одно ядро, а вы хотите выжать больше из многоядерного VDS без немедленного перехода к кластеру, смотрите на DragonflyDB. Но относитесь к нему как к инженерному решению, а не к магической замене: compatibility test, нагрузочный профиль, проверка персистентности и план отката обязательны.
KeyDB остаётся интересным вариантом для существующих инсталляций и отдельных сценариев, где его возможности уже доказали пользу. Но для нового проекта я бы сравнивал его особенно внимательно: не только по производительности, но и по жизненному циклу, поддержке, пакетам и совместимости с текущими клиентами.
Главная мысль простая: лучший cache on VDS — не тот, который выиграл чужой benchmark, а тот, который стабильно держит ваши p95 и p99, не съедает всю память, корректно переживает restart, понятен вашей команде и не требует героизма в три часа ночи.
