Redis 8.6 — x5 throughput это реально или маркетинг?

[zhenya_docker]

Redis выкатили 8.6 с заявлениями про x5 throughput против Redis 7.2 и 3.5 млн ops/sec с пайплайнингом. Звучит как маркетинговая цифра. Кто-нибудь проверял на реальной нагрузке, не в синтетическом бенчмарке? У нас Redis 7.2.6 на выделенном сервере (32 cores, 128 GB RAM), используем как кэш и для rate limiting, пиковая нагрузка ~400k ops/sec. Стоит ли обновляться и чего реально ожидать?

[tanya_loop67]

Проверял на стенде, могу поделиться цифрами. Конфигурация: Redis 7.2.6 vs 8.4 (до 8.6 ещё не добрался), сервер 16 cores, тест через redis-benchmark -c 200 -n 5000000 -t get,set.

Redis 7.2: GET ~380k ops/sec, SET ~290k ops/sec
Redis 8.4: GET ~680k ops/sec, SET ~510k ops/sec

Прирост реальный, около x1.8 в моём тесте. До x5 далеко, но это синтетика с пайплайнингом на идеальных условиях. В реальной нагрузке с разнообразными командами и сетевыми задержками — думаю x1.5-2 это честная оценка. Для 400k ops/sec на 32 cores у вас огромный запас.

[denis_dev]

@sd_artist, x5 достигается с пайплайнингом включённым и на конкретных командах (GET/SET строк). В Redis 8 добавили нормальный I/O threading — теперь чтение сокетов и парсинг команд вынесены в отдельные потоки, основной event loop разгружен. Это действительно серьёзное архитектурное изменение которого ждали много лет. Но если у вас команды типа ZADD/ZRANGE или Lua скрипты — прирост будет меньше.

По latency: p50 и p99 заметно улучшились. На sorted set командах p99 снизился на 35% в 8.6 против 8.4. Это важнее throughput для большинства приложений.

[jscode1641]

Главная фича Redis 8 которую все забывают упомянуть: модули теперь встроены в ядро. RedisJSON, RediSearch, RedisTimeSeries, RedisBloom — больше не нужно грузить отдельно. Это упрощает деплой и означает что они теперь official supported часть Redis. Если вы используете JSON тип данных или full-text поиск через Redis — обновление само по себе оправдано.

[oleg_linux]

Для вашей нагрузки (400k ops/sec на 32 cores) — вы даже на Redis 7.2 не упираетесь в потолок. Основной аргумент для обновления не throughput, а latency stability. Redis 7.2 при RDB snapshot или AOF rewrite иногда давал спайки latency. Redis 8 с улучшенным replication буфером (пиковый буфер на 35% меньше) и оптимизированным snapshot стал стабильнее. Меньше спайков = лучше p99 в проде.

[semyon_api62]

Миграция с 7.2 на 8.x — относительно безболезненная. Формат RDB совместим, основные breaking changes касались некоторых конфигурационных параметров которые переименовали. Проверьте через redis-check-rdb ваш дамп перед миграцией и прочитайте migration guide — там минут 20 работы. Мы переехали через replica promotion: подняли реплику на 8.x, убедились что данные нормальные, сделали failover. Даунтайм — несколько секунд.