Cache Consistency Issues and Solutions: Cache‑Aside Pattern, Lazy Deletion, and Queue‑Based Synchronization

Cache Aside Pattern

The classic read‑write model for cache and database is the Cache‑Aside pattern: on a read, first check the cache, fall back to the database if missing, then populate the cache; on an update, write to the database first and then delete the cache entry.

Why Delete the Cache Instead of Updating It?

Complex cache values often require data from multiple tables and expensive calculations; updating such a cache on every database change would be costly. Deleting the cache implements a lazy‑calculation approach, recomputing the value only when it is actually needed.

Basic Cache‑Inconsistency Problem and Solution

Problem: updating the database first and then deleting the cache can leave the cache stale if the delete fails. Solution: delete the cache first, then update the database; if the database update fails, the cache remains empty, avoiding inconsistency.

Analysis of More Complex Inconsistency Scenarios

When a cache entry is deleted before the database update completes, a concurrent read may fetch the old value from the database, store it in the cache, and later the database is updated, leaving the cache out‑of‑date.

High‑Concurrency Solution Using an Internal JVM Queue

Each data item is routed by its unique identifier to a dedicated internal queue. A single worker thread processes the queue serially: it first deletes the cache, then updates the database. If a read arrives while the cache is empty, the read request is also queued, ensuring the cache is refreshed only after the database commit.

Optimization: filter duplicate cache‑update requests in the queue so that only the latest update is performed, reducing unnecessary work.

Key Risks and Operational Considerations

1. Read request blocking : because reads are lightly asynchronous, they must respect timeout limits; excessive queue buildup can cause timeouts and force reads to hit the database.

2. High write frequency : a surge of write operations can overflow the queue, leading to many read timeouts; capacity planning and load testing are essential.

3. Service instance routing : all update and cache‑refresh requests for the same data should be routed to the same service instance (e.g., via Nginx hash routing) to preserve ordering.

4. Hot‑item skew : if a particular item receives a disproportionate number of reads/writes, its queue may become a bottleneck; scaling out with more instances or sharding can mitigate this.

Overall, the queue‑based serial processing model, combined with lazy cache deletion and careful routing, provides a practical way to maintain cache‑database consistency under high concurrency.

作者：你是我的海啸

来源：https://blog.csdn.net/chang384915878/article/details/86756463

整编：搜云库技术团队，欢迎广大技术人员投稿

投稿邮箱：[email protected]