Consistency

Cache Update Strategies

1. Memory Eviction: Redis automatically evicts data when memory is low; cache updated on next request.
2. TTL Expiry: Set TTL on cached data; deleted automatically when expired; updated on next request.
3. Active Update: Update cache simultaneously with database modification.

Cache-Database Consistency

Concurrent requests can cause inconsistency regardless of update order (cache first or database first).

Use Cache Aside strategy: cache only updated during read operations.

• Write strategy: When modifying data, update database and delete cache.
• Read strategy: When reading data, if cache miss, read from database and update cache.

Update-Then-Delete (Delayed Double Delete)

Thread A reading, Thread B updating simultaneously:

1. Thread A cache miss, reads DB x=20
2. Thread B updates DB x=21
3. Thread B deletes cache (first delete)
4. Thread A writes stale data to cache x=20
5. Thread B delays briefly then executes second delete (active, not passive)

• Low probability: steps 1-4 usually complete faster than DB query+update.
• Delay time (e.g., 500ms) should exceed “query DB + write cache” duration (typically < 100ms).
• Proper delay covers Thread A’s stale write (step 4).
• Repeated deletion is safe and idempotent even without conflicts.

What if cache deletion fails?

Use @Transactional. If cache deletion fails, database update should roll back. Other methods

Shop Cache Implementation

Use active update + TTL expiry strategy.

1. Query shop by ID: if cache miss, read DB, write to cache with TTL.
2. When modifying data: update database first, then delete cache.

Store Shop object as JSON string in Redis. Suitable for complex objects with infrequent updates.

For frequent updates, consider storing as Redis hash.

Cache Utility Class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@Slf4j
@Component
public class CacheClient {

    private final StringRedisTemplate stringRedisTemplate;

    private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

    public CacheClient(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    public void set(String key, Object value, Long time, TimeUnit unit) {
        stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value), time, unit);
    }
}

StringRedisTemplate is auto-configured by Spring Boot based on application.yml. Spring creates a singleton instance.

CacheClient is a @Component bean. Spring injects StringRedisTemplate via constructor injection.

Cache Penetration

Requests for data that doesn’t exist in cache or database. High volume can overload database.

1. Cache null values: When DB query returns empty, store null in Redis.
2. Bloom Filter: Pre-load all existing product IDs into bloom filter.
   • Check bloom filter first; if not present, return “not exists”; otherwise proceed to cache/DB.

Cache Avalanche

Massive cache key expiry/Redis downtime simultaneously, flooding database with requests. Solution: Set random expiry times; use Redis cluster.

Cache Breakdown

Hot key with complex rebuild logic expires. Many concurrent requests hit database simultaneously. Solution: Logical expiry + mutual exclusion lock.

When Redis cache expires for a merchant, attempt to acquire lock. If successful, spawn thread to rebuild cache while current thread returns stale data immediately.