Кеширование
Инвалидация кэша: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый — решение, которое ты принимаешь в реальном инциденте: не стратегия, которую надо назвать, а разрыв несвежести, который надо взвесить против того, что твой продукт способен терпеть.
Убедись, что связываешь TTL-стампиды, проблему dual-write, гонку set-after-delete и стратегии пути записи — тот синтез, к которому вёл урок: каждая стратегия отгружает свою несвежесть.
1000 серверов приложения кэшируют один горячий ключ с одинаковым TTL 300 с, все прогреты в одном деплое. В момент T=300 origin получает удар на ~100 мс. Какой самый чистый первый фикс и почему он работает?
Ты используешь cache-aside с delete-on-write: обновить БД, затем DEL ключа. Пользователь жалуется, что его правка профиля откатывается на часы. Самая вероятная первопричина?
Почему удалять ключ кэша на записи — сеньорский рефлекс, а не обновлять его новым значением?
Команда активно инвалидирует на каждой записи и предлагает убрать TTL целиком, «раз мы всегда делаем purge». Что ломается?
Пользователь редактирует свой профиль и должен сразу увидеть новое значение (read-your-writes обязателен). Какая стратегия записи держит это с наименьшим риском гонки?
Горячий ключ под cache-aside ловит гонку set-after-delete на каждой правке профиля. Нужен сильнейший фикс, который ещё и снижает нагрузку на origin. За чем тянешься?
Сквозная мысль одной фразой: инвалидация — это выбор, какую несвежесть отгрузить. TTL — дешёвый пол, ограниченный, но склонный к синхронным стампидам, которые гасишь jitter. Event-driven purge режет несвежесть до записи, но это dual-write, поэтому держишь TTL как страховку для каждого пропущенного DEL. Delete бьёт update, потому что идемпотентен и независим от порядка, но всё равно гоняется с параллельным читателем — гонка set-after-delete — закрываемая delayed double-delete, лизами (которые ещё и срезали нагрузку Facebook на горячий ключ) или прогоном записей через кэш. А стратегия записи — это решение про read-your-writes: write-through держит его, write-around ломает, write-behind рискует durability.