Choosing the Right Cache Consistency Strategy for Redis‑MySQL Integration

Background

Cache is a useful concept in software development; database caching is common, and ensuring cache consistency is a frequent interview question. This article summarizes consistency solutions for different requirements.

What is Cache

Cache stores results of slower storage in faster storage.

The upper layer of the storage pyramid can serve as cache for the lower layer.

This discussion focuses on database cache, using Redis as a cache for MySQL.

Why Use Cache

MySQL provides full ACID but performance is limited under high concurrency, creating pressure and latency.

According to the locality principle, 80% of requests hit 20% of hot data; in read‑heavy, write‑light scenarios, adding a cache improves throughput and robustness.

Problems

Data in the database may change, causing cache inconsistency. The tolerable staleness depends on business, but most require eventual consistency.

Redis as MySQL Cache

Typical architecture uses MySQL for storage and Redis as cache. When MySQL updates, how to keep Redis synchronized?

Strong consistency is costly; most scenarios aim for eventual consistency.

Solution 1

Rely on key expiration; do not update Redis when MySQL changes.

Simple to implement but may cause long periods of inconsistency, especially with frequent reads and long TTL.

Advantages:

Low development cost, easy to implement.

Low management cost, low failure probability.

Disadvantages:

Depends entirely on TTL; short TTL leads to frequent cache misses, long TTL leads to stale data.

Solution 2

Based on Solution 1, add a write‑through step: update Redis together with MySQL.

Advantages:

Update latency smaller than Solution 1.

Disadvantages:

If MySQL update succeeds but Redis update fails, it degrades to Solution 1.

In high‑concurrency, the business server must maintain connections to both MySQL and Redis, doubling connection resources and risking connection exhaustion.

Solution 3

Improve Solution 2 by introducing a message queue (Kafka) to handle Redis updates asynchronously.

Advantages:

Message queue can batch messages, reducing connection pressure.

Achieves logical decoupling.

Reliability of the queue ensures at‑least‑once delivery to Redis.

Disadvantages:

Does not solve ordering issues; concurrent updates may be applied out of order.

Additional service for consuming messages adds cost and risk of duplicate consumption.

Solution 4

Subscribe to MySQL binlog and update Redis via a consumer service acting as a MySQL slave.

Advantages:

Low latency when MySQL load is modest.

Fully decoupled from business logic.

Solves ordering problems.

Disadvantages:

Requires building a separate synchronization service and implementing binlog replication, which incurs significant cost.

Conclusion

Choosing a Solution

If the product tolerates some delay, use Solution 1; it is simple and widely adopted for read‑heavy, write‑light workloads.

For more immediate updates, consider Solution 2, but without heavy retry mechanisms.

Solutions 3 and 4 target scenarios with strict latency requirements; Solution 4 offers stronger reliability and ordering.

Final Recommendation

Generally, Solution 1 suffices. For high‑latency demands, choose Solution 4. In interview settings, start with the simple solution and progressively discuss more complex ones.