Кэш и производительность

Сколько именно он даёт

Считаем на цифрах карточки. База отвечает за 40 миллисекунд, кэш в памяти - примерно за 1. Если попадание случается в девяти случаях из десяти, средняя задержка выходит 0,9 умножить на 1 плюс 0,1 умножить на 40 - это 4,9 миллисекунды вместо сорока, примерно в восемь раз быстрее.

Нагрузка падает так же: из тысячи запросов в секунду до базы доходит сотня. Обычно ради этого кэш и ставят - не ради миллисекунд на экране, а ради снятой с источника нагрузки.

// Доля попаданий - главный показатель кэша. Упала до 20 процентов, и средняя задержка становится 0,2 умножить на 1 плюс 0,8 умножить на 40, то есть 32 миллисекунды. Выигрыша почти нет, зато память занята и появилось ещё одно место, где данные бывают неправильными.

доля попаданий

процент запросов, на которые ответил кэш, не обращаясь к источнику

Главный вопрос - допустимое отставание

Вопрос бизнесовый, и ответ на него определяет всю конструкцию. Цена может отставать на час - ставим TTL (time to live), срок годности записи, и задача решается за день. Расхождение недопустимо даже на минуту, потому что человек увидит одну цену, а спишется другая - нужен сброс по событию изменения цены, отдельный надёжный канал событий и совсем другой объём работы.

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

// Сброс по событию даёт свежесть почти мгновенно, но платит хрупкостью: одно потерянное сообщение оставит неверное значение висеть до следующего изменения, а оно может случиться через неделю. Поэтому даже при сбросе по событию срок годности оставляют как страховку.

Кэш - тоже хранилище данных

Клиент потребовал удалить персональные данные. Из базы удалили, а копия в кэше дожила до конца срока годности - сутки. Сутки обязательство не выполнено, и это проверяемое нарушение, а не мелочь.

Значит в требованиях появляются три строчки: ограниченный срок хранения, шифрование там, где данные того требуют, и явный сброс кэша при удалении клиента. Само это никто не вспомнит.

// Второй забываемый случай - холодный старт. Система живёт на кэше и отправляет в базу сотню запросов в секунду. После перезапуска кэш пуст, и в базу летит вся тысяча - вдесятеро больше, чем она рассчитана держать. Лечится прогревом до ввода в строй или пропуском части запросов, пока кэш наполняется.

Что кэшировать бесполезно

Выдачу поиска по произвольным фильтрам. Ключом служит сочетание всех параметров: при десяти фильтрах по пять значений комбинаций получается пять в десятой степени - 9 765 625, почти десять миллионов. Каждый запрос уникален, попаданий нет, память занята зря.

Работает другое: кэшировать популярные предустановленные наборы («новинки», «со скидкой») и отдельные карточки товаров, которые переиспользуются между разными выдачами. Тогда список собирается из горячих кусков, даже если сам список никто раньше не запрашивал.

// Проверяемое требование к кэшу выглядит так: «данные не старше 60 секунд с момента изменения; при устаревании показывается последнее известное значение с отметкой времени; есть ручка принудительного обновления». Формулировка «кэш должен работать быстро» не проверяется ничем.

Как отвечать: «Вводим кэш на цены. Что выяснишь у бизнеса первым делом?»

Какое отставание цены допустимо и что делаем, если клиент увидел старую. Это не техническая мелочь: если расхождение недопустимо, потому что человек оформит заказ по одной цене, а спишется другая, простым сроком годности не обойтись - нужен сброс по событию изменения цены, а это надёжный канал событий и разбор потерянных сообщений. Если же час отставания никого не смущает, задача решается за день на TTL. Дальше уточню два пункта, про которые обычно забывают: срок хранения копии и её удаление вместе с персональными данными клиента, и поведение после перезапуска - кэш пуст, и вся нагрузка уходит в базу разом.

Кандидат ставит бизнес-вопрос перед техническим решением, показывает разницу в трудоёмкости и помнит про персональные данные и холодный старт.

На чём валятся

• −− Решают вопрос о кэше технически, не спросив про допустимое отставание.
• −− Забывают про персональные данные в кэше при удалении клиента.
• −− Не готовятся к холодному старту: после перезапуска вся нагрузка падает на базу.
• −− Кэшируют выдачу поиска по произвольным фильтрам и получают долю попаданий около нуля.
• −− Полагаются только на сброс по событию, без срока годности как страховки.
• −− Пишут «кэш должен работать быстро» вместо ограничения на отставание в секундах.