Кеширование
Инвалидация кэша: свободное припоминание
Припоминание бьёт перечитывание. На каждый вопрос проговори или напиши полный ответ по памяти, прежде чем открыть модельный — именно усилие извлечения закрепляет модель консистентности к моменту, когда инцидент прилетит в три часа ночи.
Восстанови костяк юнита — почему инвалидация это выбор несвежести, гонка set-after-delete и три её фикса, почему TTL остаётся даже при активном purge и что покупает каждая стратегия записи — не подглядывая в урок.
- 01Почему инвалидацию кэша формулируют как «выбор, какую несвежесть отгрузить», а не как задачу, которую можно решить целиком?
- 02Пройди гонку set-after-delete по шагам и назови три способа закрыть её в порядке возрастания стоимости.
- 03Почему держать TTL даже при активной инвалидации на каждой записи, и что такое проблема dual-write?
- 04Что такое thundering herd от синхронизированного истечения TTL и как jitter и probabilistic early refresh его гасят?
- 05Почему удалять ключ кэша на записи, а не обновлять его новым значением?
- 06Сравни write-through, write-behind и write-around: что каждый покупает и что ломает.
Если ты восстановил каждый ответ по памяти, ты держишь костяк юнита: инвалидация — это выбор несвежести, потому что кэш и БД не делят транзакцию; гонка set-after-delete — это production-ловушка, закрываемая double-delete, лизами или write-through; TTL остаётся даже при активном purge как страховка для dual-write, который тихо падает; синхронизированное истечение стампидит origin, гасится jitter и probabilistic early refresh; delete бьёт update, потому что идемпотентен и независим от порядка; а стратегия записи — through, behind, around — это решение read-your-writes-против-durability.