Cache invalidation стратегии: TTL, eviction, distributed cache consistency?

#Стратегии

#TTL и jitter

var ttl = TimeSpan.FromMinutes(10) + TimeSpan.FromSeconds(Random.Shared.Next(-60, 60));   // 9–11 минут
await cache.SetAsync(key, value, new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = ttl });

Как выбирать TTL: какая задержка устаревания допустима бизнесу («цена может обновиться через 5 минут» — ок; «баланс счёта» — нет, не кэшировать или инвалидировать явно) и какая нагрузка на источник при промахах.

#Инвалидация при записи: delete, а не update

public async Task UpdatePriceAsync(int productId, decimal price, CancellationToken ct)
{
    await db.Products.Where(p => p.Id == productId).ExecuteUpdateAsync(s => s.SetProperty(p => p.Price, price), ct);
    await cache.RemoveAsync($"product:{productId}", ct);        // после успешной записи в БД
    await cache.RemoveByTagAsync($"category:{categoryId}", ct);  // зависимые списки (HybridCache)
}

#Гонка «устаревшее значение возвращается в кэш»

Смягчение:

• TTL всегда — ограничивает время жизни ошибки.
• Delayed double delete: удалить сразу и ещё раз через небольшую задержку (сотни мс).
• Версии: хранить в кэше вместе с version/updated_at и не перезаписывать более новую версию более старой (Lua-скрипт в Redis с проверкой).
• Для критичных данных — не кэшировать или читать из источника.

#Групповая инвалидация

// Ключи включают «поколение» категории; инвалидация = увеличить поколение
var gen = await redis.StringGetAsync($"gen:category:{categoryId}") ;
var key = $"category:{categoryId}:g{gen}:page:{page}";

// При изменении любого товара категории
await redis.StringIncrementAsync($"gen:category:{categoryId}");   // старые ключи больше не читаются, истекут по TTL

HybridCache (.NET 9+) и Output Cache поддерживают теги «из коробки»: RemoveByTagAsync("category:5").

#Eviction

maxmemory 2gb
maxmemory-policy allkeys-lru        # для чистого кэша; volatile-lru — вытеснять только ключи с TTL

IMemoryCache с SizeLimit вытесняет по приоритету (CacheItemPriority) и давности использования при компактизации.

#Паттерны записи

#Несколько экземпляров и локальные кэши

var sub = redis.GetSubscriber();
await sub.SubscribeAsync(RedisChannel.Literal("cache:invalidate"), (_, key) => memoryCache.Remove(key.ToString()));

// после записи
await sub.PublishAsync(RedisChannel.Literal("cache:invalidate"), $"product:{id}");

Pub/Sub в Redis — «fire and forget»: отключённый в момент публикации экземпляр сообщение пропустит. Поэтому короткий TTL для L1 остаётся страховкой. В микросервисах инвалидацию часто делают по доменным событиям из брокера (ProductPriceChanged).

#Вопросы на засыпку

#Итог

Инвалидация — это баланс свежести и нагрузки. TTL с jitter — базовая страховка, удаление ключей после записи (а не обновление) — быстрая реакция, теги и версии — групповая инвалидация, Pub/Sub, события или CDC — согласованность нескольких экземпляров. Вытеснение (LRU и др.) — управление памятью, а не свежестью. Помните о гонках cache-aside и не кэшируйте то, что должно быть строго актуальным.