Какие знаешь способы для обновления актуальности данных в Redis?

Способы обновления актуальности данных в Redis

Redis — это in-memory хранилище, которое часто используется как кэш. Однако кэши имеют проблему: данные в кэше могут устаревать. Существует несколько подходов к поддержанию актуальности данных в Redis.

1. Time-To-Live (TTL) — Автоматическое истечение

Самый простой способ — установить время жизни ключа

// Установить TTL при создании
redisTemplate.opsForValue().set(
    "user:1:profile", 
    userProfile, 
    Duration.ofHours(1)  // Истечёт через 1 час
);

// Или использовать SETEX
redisTemplate.execute((RedisConnection conn) -> {
    conn.setEx(
        "user:1:profile".getBytes(),
        3600,  // 1 час в секундах
        userProfile.getBytes()
    );
    return null;
});

Проблемы:

• Кэш истекает в фиксированный момент, даже если данные ещё актуальны
• При интенсивном доступе может быть много одновременных запросов к БД при истечении TTL
• Слишком короткий TTL — частые обновления БД
• Слишком длинный TTL — устаревшие данные

Рекомендация: Используй TTL как базовую защиту от совсем старых данных

redisTemplate.expire("user:1:profile", Duration.ofHours(24));

2. Lazy Loading (Ленивая загрузка)

При доступе к кэшу проверяется TTL, и если ключа нет, данные загружаются заново

public UserProfile getUserProfile(Long userId) {
    String key = "user:" + userId + ":profile";
    
    // Попытка получить из кэша
    UserProfile cached = redisTemplate.opsForValue().get(key);
    if (cached != null) {
        return cached;  // Кэш попал
    }
    
    // Cache miss — загружаем из БД
    UserProfile fresh = userRepository.findById(userId).orElseThrow();
    
    // Сохраняем в кэш с TTL
    redisTemplate.opsForValue().set(
        key, 
        fresh, 
        Duration.ofHours(1)
    );
    
    return fresh;
}

Проблемы:

• Cache Stampede (Thundering Herd) — когда ключ истекает, множество потоков пытаются загрузить данные одновременно
• Первые запросы после истечения TTL идут в БД
• Пики нагрузки при истечении популярных ключей

Решение — использовать Lock:

public UserProfile getUserProfile(Long userId) {
    String key = "user:" + userId + ":profile";
    String lockKey = key + ":lock";
    
    UserProfile cached = redisTemplate.opsForValue().get(key);
    if (cached != null) {
        return cached;
    }
    
    // Пытаемся захватить lock
    Boolean lockAcquired = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, "locked", Duration.ofSeconds(5));
    
    if (lockAcquired) {
        try {
            // Мы захватили lock, загружаем из БД
            UserProfile fresh = userRepository.findById(userId).orElseThrow();
            redisTemplate.opsForValue().set(key, fresh, Duration.ofHours(1));
            return fresh;
        } finally {
            redisTemplate.delete(lockKey);
        }
    } else {
        // Lock захватил другой поток, ждём
        Thread.sleep(100);
        return getUserProfile(userId);  // Retry
    }
}

3. Proactive Refresh (Активное обновление)

Обновлять кэш ДО истечения TTL, пока данные ещё актуальны

public UserProfile getUserProfile(Long userId) {
    String key = "user:" + userId + ":profile";
    String ttlKey = key + ":ttl";
    
    UserProfile cached = redisTemplate.opsForValue().get(key);
    Long ttl = redisTemplate.getExpire(key, TimeUnit.SECONDS);
    
    // Если TTL менее 5 минут, обновляем в фоне
    if (ttl != null && ttl < 300) {
        // Запустить фоновое обновление
        executorService.submit(() -> {
            UserProfile fresh = userRepository.findById(userId).orElseThrow();
            redisTemplate.opsForValue().set(
                key, 
                fresh, 
                Duration.ofHours(1)
            );
        });
    }
    
    return cached != null ? cached : fallbackLoad(userId);
}

Преимущества:

• Нет cache stampede
• Пользователи всегда получают свежие данные
• Плавная нагрузка на БД

Проблемы:

• Требует отдельного потока/сервиса
• Сложнее в реализации
• Может перегружать БД постоянными обновлениями

4. Event-Based Invalidation (Инвалидация на основе событий)

Когда данные в БД изменяются, инвалидируем соответствующий кэш

@Service
public class UserService {
    
    @Autowired
    private RedisTemplate<String, UserProfile> redisTemplate;
    
    @Autowired
    private ApplicationEventPublisher eventPublisher;
    
    public void updateUserProfile(Long userId, UserProfile newProfile) {
        // Обновляем БД
        userRepository.save(newProfile);
        
        // Инвалидируем кэш
        String key = "user:" + userId + ":profile";
        redisTemplate.delete(key);
        
        // Публикуем событие для других сервисов
        eventPublisher.publishEvent(
            new UserProfileUpdatedEvent(userId, newProfile)
        );
    }
}

@EventListener
public void onUserProfileUpdated(UserProfileUpdatedEvent event) {
    // Другие компоненты могут реагировать на событие
    // Например, обновить кэш в других местах
}

Более сложный пример с Kafka:

// Когда БД обновляется, отправляем событие в Kafka
kafkaTemplate.send("user-updates", userId, newProfile);

// Другой сервис слушает Kafka
@KafkaListener(topics = "user-updates")
public void handleUserUpdate(Long userId, UserProfile profile) {
    String key = "user:" + userId + ":profile";
    redisTemplate.opsForValue().set(key, profile, Duration.ofHours(1));
}

Преимущества:

• Данные обновляются только когда они действительно изменяются
• Нет ненужных обновлений
• Контролируемая нагрузка на БД

Проблемы:

• Сложная архитектура (требует системы событий)
• Может быть задержка между изменением и инвалидацией
• Нужно отслеживать все места, где изменяются данные

5. Cache-Aside Pattern (Паттерн рядом с кэшем)

Общий паттерн, комбинирующий несколько подходов

public UserProfile getUser(Long userId) {
    String key = "user:" + userId;
    
    // Step 1: Try to get from cache
    UserProfile user = (UserProfile) redisTemplate.opsForValue().get(key);
    
    // Step 2: If not in cache, get from database
    if (user == null) {
        user = userRepository.findById(userId).orElseThrow();
        
        // Step 3: Put it in cache for future use
        redisTemplate.opsForValue().set(
            key, 
            user, 
            Duration.ofHours(1)
        );
    }
    
    return user;
}

public void updateUser(Long userId, UserProfile updated) {
    // Step 1: Update database
    userRepository.save(updated);
    
    // Step 2: Invalidate cache
    redisTemplate.delete("user:" + userId);
}

6. Write-Through Pattern (Паттерн сквозь запись)

При записи сначала пишем в БД, затем в кэш

public void saveUser(UserProfile user) {
    // Step 1: Write to database
    UserProfile saved = userRepository.save(user);
    
    // Step 2: Update cache immediately
    redisTemplate.opsForValue().set(
        "user:" + saved.getId(),
        saved,
        Duration.ofHours(1)
    );
}

7. Versioning (Версионирование)

Использовать версии данных вместо простого TTL

public class CachedUser {
    private UserProfile profile;
    private Long version;  // Версия из БД
    private long cacheTime;
}

public UserProfile getUser(Long userId) {
    String key = "user:" + userId;
    CachedUser cached = redisTemplate.opsForValue().get(key);
    
    // Проверяем версию в БД
    Long dbVersion = userRepository.getVersion(userId);
    
    if (cached != null && cached.version.equals(dbVersion)) {
        // Версии совпадают, кэш актуален
        return cached.profile;
    }
    
    // Версии не совпадают, перезагружаем
    UserProfile fresh = userRepository.findById(userId).orElseThrow();
    CachedUser updated = new CachedUser(
        fresh, 
        dbVersion,
        System.currentTimeMillis()
    );
    
    redisTemplate.opsForValue().set(key, updated, Duration.ofHours(1));
    return fresh;
}

Сравнение подходов

Рекомендации

1. Начни с простого TTL для большинства случаев
2. Используй Proactive Refresh для популярных данных
3. Event-Based Invalidation для критичных данных
4. Cache-Aside — универсальный паттерн, используй как базу
5. Комбинируй подходы — например, TTL + Event-Based
6. Мониторь — отслеживай hit rate, miss rate, обновления БД
7. Тестируй — убедись, что кэш не приводит к race conditions

// Пример комбинированного подхода
public UserProfile getUser(Long userId) {
    String key = "user:" + userId;
    CachedUser cached = redisTemplate.opsForValue().get(key);
    
    // TTL + версионирование
    if (cached != null) {
        if (isVersionStale(cached.version)) {
            // Версия устарела, но кэш может быть полезен
            return cached.profile;  // Используем старый
        }
        return cached.profile;  // Кэш актуален
    }
    
    // Cache miss — Lazy Loading с lock
    return loadWithLock(userId, key);
}