How to Ensure MySQL‑Redis Data Synchronization Consistency (High‑Frequency Interview Question)

1. Overview

In modern distributed business systems MySQL and Redis are frequently used together to combine strong consistency and persistence (MySQL) with fast in‑memory reads and writes (Redis). Ensuring data consistency between them is a critical and challenging problem.

2. Consistency Problems in High Concurrency

Four possible write orders exist, each of which can break consistency when many requests execute concurrently.

2.1 Write MySQL first, then Redis

If request A stalls while writing to Redis, request B may finish both writes first, causing the cache to hold A’s old value while the database holds B’s new value. The stale cache persists until expiration.

2.2 Write Redis first, then MySQL

The order is reversed: the cache receives request B’s value while the database receives request A’s value, again producing inconsistency.

2.3 Delete Redis first, then update MySQL

When the cache is deleted before the database update, a subsequent read may repopulate the cache with the old value while the database already holds the new value.

2.4 Update MySQL first, then delete cache (Cache‑Aside)

This is the most common and recommended pattern. After the database write, the cache entry is removed so the next read fetches the fresh data from MySQL and repopulates the cache. Because cache writes are usually faster than database writes, the window of inconsistency is very small.

2.5 Delayed Double Delete

The process deletes the cache, updates the database, sleeps for a configurable period, then deletes the cache again. The delay aims to let any in‑flight reads finish before the second delete, but the sleep duration is unpredictable and harms write performance, so this approach is generally discouraged.

Delete cache

Update database

Sleep for a short time

Delete cache again

3. Consistency Solutions

Strong consistency between MySQL and Redis is unattainable because the two operations are non‑atomic. Systems therefore aim for eventual consistency while minimizing latency.

One practical method is to add a distributed lock before updating the cache, ensuring only one thread can refresh the cache at a time. This adds some write latency but prevents race conditions.

3.1 Message Queues

Most systems already use MQs such as Kafka, RocketMQ, or RabbitMQ for core business events (e.g., order changes). By adding a consumer that writes the updated data to Redis, the cache can be kept in sync. Reliability of the message pipeline is essential because lost messages would leave the cache permanently stale.

3.2 Canal‑Based Binlog Subscription

Canal parses MySQL binlog streams by acting as a slave node, converting raw binlog bytes into structured change events that downstream services can consume to update Redis in real time.

4. Summary

MySQL‑Redis data consistency is a classic distributed‑system challenge. Strong consistency is impossible without costly distributed transactions, so most designs settle for eventual consistency, using strategies such as Cache‑Aside with short TTLs, distributed locks, message‑queue‑driven sync, or Canal binlog subscription. For low‑concurrency business systems, the simple Cache‑Aside pattern with a reasonable cache expiration time is often sufficient.