Как мы прессовали Redis — и остались в живых

Да, спасибо, мы эту информацию учитывали при выборе замены Redis, сами эксперименты проводились достаточно давно, поэтому сначала рассматривали KeyDB.

Как мы прессовали Redis — и остались в живых

Привет, сейчас будет использоваться так называемый zero downtime cache, при котором будет поднята "пустая" реплика и на нее будет производиться переключение траффика (время переключения секунды, чтобы не было ложных срабатываний). Мы знаем что реплика пустая и готовы к тому что временно она будет прогреваться (по нашим замерам 4-5 минут), но это для нас не является критичным.

Как мы прессовали Redis — и остались в живых

Привет, по проценту потерь цифру уже назвать не смогу, так как дело было давно и метрики давно потерлись, но по поиску проблемы это была проверка и сопоставления множества метрик, анализ физической сети, по итогу команда `tc -s qdisc show dev ifb0` указала на проблемы.

Как мы прессовали Redis — и остались в живых

Сделать такое нам не представлялось возможным в силу некоторых ограничений, больше тут не смогу прокомментировать, к сожалению :)

Как мы прессовали Redis — и остались в живых

1. Метрики со стороны приложения.

2. Да, BGSAVE работает в дочернем процессе (см fork()), как раз таки запись на диск "подъедает" iops'ы, да еще и если на "железке" диск "медленный" или уже нагружен (например запись, вытеснение ключей), это может привести к увеличению задержек для всех операций, требующих записи на диск (а мы как раз пишем немало, да еще и с небольшим TTL). Еще один момент с вытеснением ключей, что мы переставали влезать в буфер репликации.
   Да и если не ошибаюсь, при настроенной репликации , мастер должен отправить RDB файл репликам, что создает дополнительную сетевую нагрузку (см. проблему с дропом пакетов).

Как мы прессовали Redis — и остались в живых

Да, развернутый нами Redis (на отдельной железке с почти дефолтными настройками) выдавал десятки тысяч рпс на ядро, а вот DBaaS нет, собственно причин было несколько, некорректная работа с таймаутами, баг в настройке оберткb над утилитой tcО из-за которого просиходил дроп пакетов когда не должен был происходить + репликация (которая нужна была только чтобы в случае недоступности мастера переключиться на что-то живое и с данными, мы с них не читали!) + снятие снэпшотов раз в N времени, все это накладывало доп нагрузку из-за которой Редис работал не на пике своих возможностей.

Как мы прессовали Redis — и остались в живых

В теории может быть (тут надо проводить тесты именно на нашем профиле нагрузки), но выбор Redis-like БД командой DBaaS был обусловлен не только скоростью (хотя это тоже немаловажно), но и множеством других факторов и по их совокупности на данном этапе решили остановиться на Valkey.

Как мы прессовали Redis — и остались в живых

Приложение - сервис написанный на языке Go, тут был выставлен таймаут "маленький" и по его истечении мы прекращаем ждать данные с кэша

...
softCancelCtx, cancel := context.WithTimeout(ctx, readTimeout)
defer cancel()
...
endch := make(chan struct{})
go func() {
    defer close(endch)
    resp, err = redisCli.Get(ctx, key).Bytes()
}()
select {
case <-softCancelCtx.Done():
    return nil, SoftCancelError
case <-endch:
    return resp, err

Клиент - библиотека для взаимодействия с Redis сервером (см redisCli в коде выше). Тут таймаут был выставлен "достаточно большой" чтобы не обрывать соединения.