Стратегии кеширования в распределённых системах — без мифов про «ещё TTL»
TL;DR
Кеш экономит повтор расчётов или чтений в рамках допустимой устарелости ответов. Важнее назвать паттерн владения (кто пишет первично, кто инвалидирует), чем бренд движка — «Redis», CDN или приложенческая мемоизация.
Определение
Стратегия кеширования фиксирует четыре контракта:
| Контракт | Вопросы |
|---|---|
| Наполнение | кто восстанавливает данные после промаха? |
| Инвалидация | когда клиент теряет доверие к байту? |
| Окно консистентности | насколько может отставать чтение от источника? |
| Поведение при сбоях | куда утекает давление без кеша? |
Опирайтесь и на официальные руководства движков, и на нейтральную статью Web cache в Википедии.
Зачем это нужно
Класс ошибок звучит как «плавающий UX»:
- эффект «обновите два раза» от гонок наполнения;
- синхронизация TTL — ловушка thundering herd;
- конфликтующие записи там, где нет нужной модели последовательности.
Интервью цепляется именно за сценарии отмены и наблюдаемости.
Сравнительная таблица
| Стратегия | Особенность записи | Профиль отставания | Ядро сложности |
|---|---|---|---|
| Cache-aside | приложение пишет в источник | TTL + явные delete | забытые delete → «зомби» |
| Read-through | промах триггерит чтение в источник | как TTL | каскадные промахи на холодном ключе |
| Write-through | кеш синхронно с записью источника | уже чаще уже | связанная латентность хвостов БД |
| Write-back | ack после записи кешу; флаш асинхронно | возможна самая длинная вилка | нужен журнал к краш‑окну |
| Write-around | горячая запись мимо топ‑кеша | читающие дольше ждут готовности | нужны метрики, что это выгоднее |
Локальная защита (singleflight, раннее обновление с джиттером) накладывается поверх базовых паттернов.
Выбор TTL должно поддерживать измерением SLA и стоимости пересборки.
Свежесть по HTTP
Edge‑CDN наследует лексику freshness‑директив, совместимую с главами семейства RFC 9110 про кеши — так проще согласовать сетевые и прикладные рассказы.
Компромиссы
| Направление | Польза | Отдача |
|---|---|---|
| Больший TTL | сильнее срезаете чтения | compliance быстрее ломает вас без ручной отмены |
| Меньший TTL | живее редакторский контент | шум давления на БД |
| Синтетический прогрев | смягчает синхронные пики | дешёвая ошибка прогноза пустует память |
| Логика в шлюзе | упрощается политика | релизы инфры сцеплены со смыслом данных |
Не называйте экономию RAM подтверждённой, пока не прогоните сценарий вытеснения во враждебных условиях.
Как упражняться в ArchiPanopticon
- Поставьте кеш/edge‑аналог между клиентом и хранилищем там, где правила топологии разрешают.
- Снимите показания без кеша — заметьте латентность и давление downstream.
- Включите кеш, сохранится ли сниженная нагрузка на узле‑данных при преобладании чтений — судите по палитре.
- Искусственно сократите TTL или увеличьте долю записи — опишите backoff или write‑around против «ударов стада».
- Подтягивайте агрегатор метрик, чтобы говорить о surrogate hit‑ratio.
Журнал гипотез к каждому прогону — как в промышленных регрессиях производительности.
FAQ
Cache-aside — «уровень стажёра»?
Часто самый управляемый для рассуждения; искусство в дисциплине удаления ключей и телеметрии.
Когда write‑behind недопустим?
Без журнального контура там, где финансовая или аудит‑целостность критична — проговорите это прямо.
CDN vs региональный кеш приложения?
Первое про географию; второе — щит от БД при повторном чтении — иногда нужны оба слоя отдельно.
Probabilistic early refresh обязательна?
Нет, но упомяните herd, если задачи синхронно бьются о один timestamp.
Как звучит частичная деградация?
Подавать протухшие ответы, пока первоисточник сломан — договоритесь, допустимо ли пользователю и как метрики это показывают.
Читать дальше
- Спецификации HTTP семейства RFC 9110 о кешах посредников.
- Google SRE — каскадные аварии: таймауты против агрессивного TTL.
- Блики Martin Fowler по CQRS/событиям — когда разделяются write‑ и read‑модели поверх кешей.