TGViewer
Алексей Рыбак: системный дизайн, хайлоад, разработка с агентами Алексей Рыбак: системный дизайн, хайлоад, разработка с агентами @rybakalexey · 10.3K subscribers
Post #185 5.12K
Вывод #3: Valkey “сгладил” родовую травму Redis, но Memcached их по-прежнему рвёт в cache-only сценарии

Disclaimer: всё, что дальше понаписано, касается исключительно специфичных кейсов, когда ваша инфра обрабатывает как минимум многие десятки/сотни тысяч запросов к кеш-слою в секунду. Если нет - вам отлично зайдёт Redis.

Третий вывод, который я сделал: Valkey действительно удалось сделать продукт, который в состоянии отдать миллион RPS с одного инстанса, а в целом Valkey отдает примерно в 2.5 раза больше RPS, чем Redis (график в презентации и в первом комментарии). У Евгения Дюкова из Яндекса был на эту тему достаточно подробный доклад на последнем хайлоаде – думаю, что скоро он окажется в свободном доступе.

Проблема (и сила) Redis заключается в простой до невозможности архитектуре. У Redis есть один единственный main thread, который отвечает “за всё”, и есть некоторое количество io-threads, которые отвечают за ввод-вывод. С ростом нагрузки, если вашему Redis можно отдать хотя бы несколько ядер, можно чуть поднять io-threads и таким образом слегка повысить пропускную способность. Это, кстати, не все знают: да, Redis можно немножечко “поскейлить” по ядрам, раза в 2 можно поднять RPS, но этот скейлинг крайне неэффективный, будет заметен рост в дипазоне 1-4 io-тредов, но дальше они начнут затыкаться в борьбе за локи (lock contention).

Что сделали в Valkey: они внесли много исправлений, позволивших “развязать” main-тред и io-треды и заметно повысили параллелизм в Redis. Плюс внесли ряд исправлений, позволивших лучше утилизировать префетч-возможности современных процессоров, что также заметно снижает latency. Короче, Valkey молодец - но родовая травма всё-таки никуда не делась. На наших тестах хорошо видно, что поднимать число io-threads выше 8-10 уже не имеет особенного смысла, сколько бы ядер у нас ни было.

В свою очередь Memcached, который конечно по сравнению c Redis/Valkey не умеет почти ничего кроме базовых get/set/del/incr операций, может выдать значительно бОльшую пропускную способность, нежели Valkey. У Memcached есть похожие проблемы с lock contention, но насколько я понимаю, используется другой подход к партиционированию данных, что снижает contention. Если вам нужен только кеш без персистенстности - Memcached по-прежнему отличный вариант.

Для справки
- Собственно презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
  • 👍 42
  • 🤮 1
More from @rybakalexey
  1. Oct 2, 2026Почему PostgreSQL 19 не вышел в сентябре и каким боком тут AI? Октябрь уж наступил, а пост…
  2. Oct 1, 2026Про Jev Набирает популярность необычная модель — Jev от TypeSafe. Это не регрессионный тра…
  3. Sep 29, 2026Друзья, приглашаем вас на очередной онлайн Devhands AI Meetup #3! В этот раз в программе д…
  4. Sep 24, 2026Алексей Рыбак: системный дизайн, хайлоад, разработка с агентами pinned a photo
  5. Sep 24, 2026Devhands — обучение в октябре Раз в месяц мы постим анонсы курсов и митапов, чтобы вы или…
  6. Sep 22, 2026На прошлой неделе я написал пост про “высокомерную иронию”, и всем спасибо, кто проголосов…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →