Ensuring Cache Consistency in High‑Concurrency Systems: Multi‑Level Strategies with Redis

Under high concurrency, Redis is often used to absorb traffic spikes, but a single Redis shard can only write about 20,000 operations per second and read about 100,000, making it insufficient for ultra‑high loads. Therefore, a multi‑level cache architecture is required.

When multiple application servers each maintain a local cache, ensuring data consistency across these caches becomes a challenge. The following common solutions are introduced.

1. MQ Synchronization Scheme

After the database updates are synchronized to Redis, an MQ message is sent to delete the corresponding local cache entries. Each application instance receives the MQ message and removes its stale local data, achieving eventual consistency.

This is the most widely adopted enterprise solution because it provides fast synchronization and reliable message delivery to all nodes. However, it introduces a third‑party MQ component, increasing system complexity, and may not suit scenarios with strict real‑time requirements.

2. Redis Pub/Sub Synchronization Scheme

Redis natively supports publish/subscribe. By using this feature instead of an external MQ, the implementation becomes simpler and lighter. However, the approach has notable drawbacks: subscribers that are offline may lose messages, and there is no persistence, making it less reliable than the MQ solution.

3. Version‑Check Scheme

Each local cache entry stores a version number alongside the business data. When reading from the local cache, the version is compared with the version stored in Redis. If they match, the data is considered consistent; otherwise, the latest data is fetched from Redis.

While this method ensures consistency, it defeats the purpose of a local cache by requiring a Redis lookup for every read, adding overhead that makes it unsuitable for high‑concurrency scenarios.

4. Automatic Refresh Scheme

Local caches like Caffeine support automatic refresh, allowing a configurable interval (e.g., 30 seconds) to pull the latest data from Redis. Within the refresh window, brief inconsistencies may occur, but the approach is simple, requires no additional development, and works well when strict consistency is not mandatory.

For caches without built‑in refresh capabilities, a scheduled task can be used to periodically sync data from Redis, though it also suffers from potential inconsistency during the interval.

Summary :

Common synchronization methods are MQ‑based sync and automatic refresh.

Local caches should have expiration times so that, even if inconsistencies arise, they eventually refresh to the latest Redis data.