Как инвалидировать кеш?

Стратегии инвалидации кэша

Инвалидация кэша — это процесс признания данных в кэше устаревшими или недействительными с целью обеспечения согласованности данных между кэшем и источником истины (базой данных, внешним API и т.д.). В контексте Go-разработки существует несколько подходов в зависимости от архитектуры и требований приложения.

Основные стратегии инвалидации

1. Инвалидация по времени (TTL - Time To Live) Наиболее распространённый подход, где каждый элемент кэша имеет заданное время жизни. После его истечения элемент автоматически удаляется или помечается как недействительный.

package main

import (
    "time"
    "github.com/go-redis/redis/v8"
)

type Cache struct {
    client *redis.Client
}

func (c *Cache) SetWithTTL(key string, value interface{}, ttl time.Duration) error {
    return c.client.Set(ctx, key, value, ttl).Err()
}

// Элемент автоматически удалится через 5 минут
cache.SetWithTTL("user:123", userData, 5*time.Minute)

2. Явная инвалидация по событию Элементы кэша удаляются или обновляются при изменении соответствующих данных в источнике истины.

func (s *UserService) UpdateUser(userID string, updates map[string]interface{}) error {
    // Обновляем данные в БД
    err := s.repo.UpdateUser(userID, updates)
    if err != nil {
        return err
    }
    
    // Инвалидируем кэш
    cacheKey := fmt.Sprintf("user:%s", userID)
    err = s.cache.Delete(cacheKey)
    if err != nil {
        // Логируем ошибку, но не прерываем операцию
        log.Printf("Failed to invalidate cache for key %s: %v", cacheKey, err)
    }
    
    return nil
}

3. Паттерн "Write-Through" Данные записываются одновременно в кэш и источник истины, что гарантирует их согласованность.

func (s *ProductService) UpdateProduct(product *Product) error {
    // Записываем в кэш
    cacheKey := fmt.Sprintf("product:%d", product.ID)
    err := s.cache.Set(cacheKey, product, 0)
    if err != nil {
        return err
    }
    
    // Записываем в БД
    return s.repo.SaveProduct(product)
}

Продвинутые техники

4. Инвалидация по тегам Позволяет инвалидировать группы связанных данных с помощью тегов.

// Установка значения с тегами
func (c *TaggedCache) SetWithTags(key string, value interface{}, tags []string) error {
    // Сохраняем значение
    err := c.Set(key, value)
    if err != nil {
        return err
    }
    
    // Для каждого тега сохраняем ссылку на ключ
    for _, tag := range tags {
        tagKey := fmt.Sprintf("tag:%s", tag)
        c.SAdd(tagKey, key)
    }
    
    return nil
}

// Инвалидация по тегу
func (c *TaggedCache) InvalidateByTag(tag string) error {
    tagKey := fmt.Sprintf("tag:%s", tag)
    
    // Получаем все ключи с этим тегом
    keys, err := c.SMembers(tagKey)
    if err != nil {
        return err
    }
    
    // Удаляем все ключи
    for _, key := range keys {
        c.Delete(key)
    }
    
    // Удаляем сам тег
    return c.Delete(tagKey)
}

5. Версионирование ключей Использование версий в ключах кэша позволяет легко инвалидировать данные, меняя версию.

func getCacheKey(userID string) string {
    // Версия кэша хранится отдельно
    cacheVersion := getCurrentCacheVersion()
    return fmt.Sprintf("v%d:user:%s", cacheVersion, userID)
}

// Инвалидация всех данных
func invalidateAllCache() {
    incrementCacheVersion()
}

Рекомендации для Go-приложений

1. Используйте контексты для управления временем жизни операций с кэшем:

func GetUser(ctx context.Context, userID string) (*User, error) {
    data, err := cache.Get(ctx, "user:"+userID)
    if err == redis.Nil {
        // Кэш-промах, загружаем из БД
        user, err := repo.GetUser(ctx, userID)
        // ... сохраняем в кэш
    }
}

1. Реализуйте механизм backoff при ошибках кэширования:

func withRetry(fn func() error, maxRetries int) error {
    for i := 0; i < maxRetries; i++ {
        err := fn()
        if err == nil {
            return nil
        }
        time.Sleep(time.Duration(i*100) * time.Millisecond)
    }
    return fmt.Errorf("max retries exceeded")
}

1. Используйте паттерн Circuit Breaker для предотвращения каскадных ошибок:

type CircuitBreaker struct {
    failures     int
    maxFailures  int
    resetTimeout time.Duration
    lastFailure  time.Time
}

func (cb *CircuitBreaker) Execute(fn func() error) error {
    if cb.failures >= cb.maxFailures {
        if time.Since(cb.lastFailure) < cb.resetTimeout {
            return ErrCircuitOpen
        }
        cb.reset()
    }
    
    err := fn()
    if err != nil {
        cb.recordFailure()
    } else {
        cb.reset()
    }
    
    return err
}

Критические аспекты

• Консистентность vs. доступность: Выбор стратегии зависит от требований CAP-теоремы
• Распределённые системы: В кластерах используйте broadcast-сообщения или централизованные менеджеры инвалидации
• Гонки данных: Решайте с помощью оптимистичных блокировок или паттерна "Cache-Aside"
• Мониторинг: Отслеживайте hit/miss ratio, размер кэша и ошибки инвалидации

Правильная стратегия инвалидации зависит от конкретного случая: read-heavy приложения часто используют TTL, тогда как write-heavy системы требуют более агрессивной инвалидации по событиям. В микросервисной архитектуре стоит рассмотреть использование event-driven инвалидации через message broker (Kafka, RabbitMQ).