Кэширование с Redis
Отдавайте горячие данные из памяти, чтобы снизить задержку и разгрузить базу
GET и SET - оно в решении, что кэшировать, насколько долго и когда это выбросить.
- правильно реализовать паттерн cache-aside (ленивая загрузка) в Express;
- выбрать разумный TTL и объяснить, что истечение срока гарантирует, а что нет;
- хранить сессии в Redis и понимать, почему это лучше памяти процесса;
- инвалидировать при записи и избегать классических ловушек устаревших данных и штурма кэша;
- рассуждать о компромиссах: согласованность, память и две трудные задачи кэширования.
1. Зачем вообще кэшировать?
Каждый запрос, доходящий до вашей базы данных или внешнего API, платит цену: сетевой цикл, планирование запроса, задержка диска или сети и конкуренция со всеми другими запросами, делающими то же самое. Если сто пользователей открывают одну и ту же страницу товара, вы выполняете один и тот же дорогой запрос сто раз, чтобы получить идентичные байты. Кэш вычисляет ответ один раз, хранит его в оперативной памяти и раздаёт копию, пока ей можно доверять.
Аналогия. Представьте загруженную кухню. База данных - это большая морозильная камера в глубине: огромная, авторитетная, но до неё далеко идти. Кэш - это маленький разделочный стол у плиты с ингредиентами, которые вы используете прямо сейчас. Вы не ходите в морозилку на каждый заказ - держите рабочий набор под рукой и пополняете, только когда закончилось. Redis и есть этот разделочный стол: быстрый, близкий и намеренно небольшой.
Убеждают два числа. Чтение SQL по первичному ключу может занять 5-40 мс с учётом сети и пула соединений; GET из Redis по той же сети обычно 0,2-1 мс. Ещё важнее, что кэш поглощает нагрузку: база видит тонкий ручеёк промахов вместо потока, поэтому остаётся здоровой при всплесках трафика.
Оговорка сразу: кэш - это вторая копия истины, а вторые копии расходятся с оригиналом. Всё сложное в кэшировании вытекает из этого одного факта. Как говорят, в информатике всего две трудные задачи: инвалидация кэша и придумывание имён.