Resolving Data Inconsistency Between Redis Cache and MySQL Database

In high‑concurrency business scenarios, the database often becomes the bottleneck, so a Redis buffer is introduced to let requests read from Redis instead of directly hitting MySQL.

While reading from the cache is straightforward, updating both the database and the cache can cause data inconsistency between Redis and MySQL. For example, if the cache is deleted before the database write completes, another thread may read an empty cache, fetch stale data from the database, and write dirty data back to Redis; conversely, if the database write fails after the cache is deleted, stale data remains in the cache.

Two main solution families are proposed:

1. Delayed Double‑Delete Strategy

Before and after writing to the database, delete the Redis key and wait a reasonable timeout (e.g., 500 ms). The pseudo‑code is:

public void write(String key, Object data){
    redis.delKey(key);
    db.updateData(data);
    Thread.sleep(500);
    redis.delKey(key);
}

Steps:

Delete the cache.

Write to the database.

Sleep for a short period (determined by the read‑logic latency, typically a few hundred milliseconds to 1 second).

Delete the cache again.

Consider the synchronization delay between Redis and the database’s master‑slave replication when choosing the sleep duration.

2. Set Cache Expiration

Assign an expiration time to cached entries so that, after the TTL expires, reads will fetch fresh data from the database, ensuring eventual consistency.

3. Asynchronous Cache Update via Binlog Subscription

Use MySQL binlog incremental subscription combined with a message queue to push updates to Redis. The workflow is:

Read hot data from Redis.

Write changes to MySQL.

Consume MySQL binlog events, publish them via a message queue (e.g., Kafka, RabbitMQ), and update Redis accordingly.

Tools such as Alibaba’s Canal can subscribe to binlog events, mimicking MySQL’s slave replication to keep Redis in sync.

Both approaches have trade‑offs: the double‑delete + TTL method may still have a brief window of inconsistency and adds latency to writes, while the asynchronous binlog method introduces complexity and depends on reliable message delivery.

For further reading, see the linked articles on Redis high availability, cache avalanche, and storage types.