Cache Working Mechanisms and Consistency Solutions Using Redis

Redis provides high‑performance read/write capabilities and is widely used as a cache to improve system performance and shield databases from high‑concurrency traffic.

Database‑cache consistency means the cached value equals the value stored in the database; inconsistency occurs when the two differ, leading to stale reads.

Common caching strategies include Cache‑Aside (the most used), Read‑Through, Write‑Through, and Write‑Behind.

Cache‑Aside (旁路缓存) reads first check the cache; on a miss the data is fetched from the database, written to the cache, and returned. The read flow can be expressed with the following pseudo‑code:

String cacheKey = "公众号：码哥字节";
String cacheValue = redisCache.get(cacheKey);
// 缓存命中
if (cacheValue != null) {
    return cacheValue;
} else {
    // 缓存缺失, 从数据库获取数据
    cacheValue = getDataFromDB();
    // 将数据写到缓存中
    redisCache.put(cacheValue);
}

Advantages of Cache‑Aside are cost‑effective cache size and simple implementation; its drawback is the extra latency on the first read when the cache is populated.

When writing with Cache‑Aside, the typical process is to write to the database first and then either update or delete the cache. Deleting the cache is preferred when the update cost is high.

Read‑Through moves the responsibility of loading data on a cache miss from the application to the cache provider, achieving separation of concerns.

Write‑Through writes to the cache first, which then synchronously writes to the database. This guarantees the cache and database are always up‑to‑date but adds write latency.

Write‑Behind writes to the cache first and updates the database asynchronously, improving application performance at the cost of weaker consistency.

In the Cache‑Aside scenario, write operations can follow four orders: (1) update cache then DB, (2) update DB then cache, (3) delete cache then DB, (4) update DB then delete cache. Scenarios where the first step succeeds and the second fails lead to inconsistency, especially under high concurrency.

Analysis of the four cases shows that the safest approach is to write to the database first, then delete the cache . This avoids stale cache data while keeping the write path simple.

Consistency‑enhancing solutions include:

Delayed double deletion: delete the cache, write to the DB, wait a short period (e.g., 500 ms), then delete the cache again.

Retry mechanism: if cache deletion fails, retry several times (possibly asynchronously via a message queue) and log failures for manual intervention.

Binlog‑based asynchronous deletion: use a tool like Canal to listen to MySQL binlog events, extract the affected keys, and delete the corresponding cache entries, with retries on failure.

Overall best practice: use the Cache‑Aside pattern, read from cache first, fall back to the database on a miss, and for writes, update the database then delete the cache. Combine this with delayed double deletion and robust retry or binlog‑driven invalidation to achieve eventual consistency while accepting the CAP‑theoretic trade‑off of AP behavior.