Mastering Distributed Cache: Programming Techniques, Sharding Strategies, and Migration Plans

1. Cache Programming Methods

Distributed caches such as Redis provide language‑specific client APIs that can be accessed directly or via higher‑level abstractions. Three practical approaches are covered:

Programming Method – Directly call the cache service in code. Example pseudocode shows fetching a user object, loading it from the database if missing, and writing it back to the cache.

Spring Injection Method – Use spring-data-redis to inject a RedisTemplate or specific operation interfaces (e.g., ListOperations) into services. The required Maven dependency and bean definitions are provided.

Annotation Method – Apply @Cacheable (and related) annotations to let Spring handle cache reads/writes transparently, eliminating repetitive code.

2. Application‑Layer Cache Access Patterns

Three common service‑level architectures are described:

Read‑Write‑Through (Double Read/Write) – Reads check the cache first; on miss, the database is queried and the result is written back. Writes update the database then the cache.

Asynchronous Update – The application only reads/writes the cache; a background service propagates changes to the database, often using MySQL binlog or similar mechanisms.

Chain (Proxy) Mode – The cache sits as a proxy layer between the application and the database, handling reads/writes based on configuration. This mode is rarely recommended for microservices due to added complexity.

3. Distributed Cache Sharding Models

When a single cache node cannot hold all data, sharding across multiple nodes is required. Three implementations are discussed:

Client‑Side Sharding – The application embeds sharding logic, often via a shared library, giving the best performance but increasing coupling.

Proxy Sharding – A dedicated proxy layer (e.g., Codis) holds routing rules, allowing developers to focus on business logic while ops manage the sharding configuration.

Cluster Sharding – The cache system itself (e.g., Redis 3.0 Cluster) provides automatic sharding and high‑availability, making the complexity transparent to the application.

4. Cache Migration Strategies

Two migration approaches are presented for expanding or rebalancing a cache cluster:

Smooth Migration (Dual‑Write) – Simultaneously write to old and new clusters, then migrate historical data, switch reads to the new cluster, and finally retire the old writes. Detailed steps with diagrams illustrate how to reuse existing shards during expansion.

Offline Migration – Stop the application, move historical data to the new cluster, reconfigure the application to point to the new cluster, and restart. This method is simpler but requires a maintenance window.

5. Cache Reliability Issues

Common problems caused by high concurrency are explained along with mitigation techniques:

Cache Penetration – Queries for non‑existent keys bypass the cache and overload the database. Solutions include caching empty values and validating input parameters.

Cache Concurrency (Stampede) – When a key expires, many requests may hit the database simultaneously. Approaches such as distributed locks, local locks, and soft expiration (application‑managed TTL) are recommended.

Cache Avalanche – Simultaneous expiration of many keys can crash the backend. Staggered TTLs with random jitter help distribute load.

6. Cache Transaction Support

Redis can provide atomic decrement operations using Lua scripts or CAS‑style transactions with WATCH / MULTI / EXEC. Both implementations return -1 on error or when the resulting value would be negative, ensuring safe counter updates.