Data Consistency Between MySQL and Redis: Strategies and Best Practices

Today we discuss data consistency, a frequent interview question at Tencent, focusing on the challenges of keeping MySQL and Redis in sync.

Bad Solutions

1. Write MySQL then Write Redis

In high‑concurrency scenarios, if request A stalls while writing to Redis and request B updates the DB first, the cache can become inconsistent. This assumes reads first check Redis and fall back to the DB without writing back to Redis.

2. Write Redis then Write MySQL

The same inconsistency issues arise as in the first case.

3. Delete Redis then Write MySQL

When the delete operation is delayed, a concurrent read request may write stale data back to Redis, leading to inconsistency.

4. Delete Redis, Write MySQL, Delete Redis Again

This "cache double‑delete" approach tries to mitigate the race condition, but using a fixed 500 ms sleep is unreliable. A better method is to enqueue delete operations and process them serially.

5. Write MySQL then Delete Redis

If the first read after the update sees stale data, a single inconsistency may occur, which is acceptable for non‑strict consistency requirements.

6. Write MySQL and Update Redis Asynchronously via Binlog

By listening to MySQL binlog events and updating Redis asynchronously, final consistency is achieved, though real‑time consistency cannot be guaranteed.

Good Solutions

4. Delete Redis → Write MySQL → Delete Redis (Cache Double‑Delete)

After writing to MySQL, delete the cache twice, the second delete being performed asynchronously via a message queue to ensure ordering.

5. Write MySQL then Delete Redis

This is recommended for real‑time scenarios: delete the cache after the DB write, retry on failure, and alert if deletion repeatedly fails.

6. Write MySQL, Use Binlog, Asynchronously Update Redis

This provides eventual consistency and is suitable for disaster recovery or data aggregation, but is not ideal for high‑concurrency flash‑sale use cases.

Key takeaways: Avoid naive "cache double‑delete" with a fixed sleep. Use message queues to serialize delete operations for reliable ordering. Implement retry mechanisms for cache deletions.

Conclusion:

Real‑time consistency: "Write MySQL then Delete Redis" offers the best trade‑off under strict latency requirements.

Eventual consistency: "Write MySQL, capture Binlog, and asynchronously update Redis" is the optimal solution for scenarios where eventual consistency is acceptable.