Лавина на популярном ключе кеша
Вопрос
Ключ с главной страницей живёт 60 секунд, читается 5000 раз в секунду, пересчёт занимает 2 секунды. В момент истечения база ложится. Какое решение лучше всего подходит для нескольких инстансов?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Варианты ответа
- Уменьшить TTL до 5 секунд, чтобы пересчёт был короче
- Обновлять заранее до истечения, пересчёт под распределённой блокировкойправильный ответ
- Убрать TTL, тогда ключ никогда не истечёт и лавины не будет
- Добавить больше реплик приложения, чтобы распределить нагрузку
Разбор
Проблема в том, что тысячи запросов одновременно видят промах и все идут пересчитывать. Лечат так: значение обновляется до истечения (фоновой задачей или вероятностно: чем ближе к концу TTL, тем выше шанс, что очередной читатель запустит обновление), а сам пересчёт защищён блокировкой (SET lock NX PX), чтобы его делал один инстанс. Остальные в это время отдают старое значение (stale-while-revalidate).
Короткий TTL делает лавины в 12 раз чаще. Бессрочный ключ без механизма обновления отдаёт вечно устаревшие данные. Больше реплик приложения увеличивает число одновременных промахов.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.