4 Patterns for MySQL-Redis Cache Consistency: Trade-offs Explained

MySQL and Redis Relationship

MySQL is the persistent database ensuring data reliability; Redis serves as a cache to boost access performance.

Why Cache Inconsistency Arises

Inconsistency only appears when data changes. Each change requires updating both database and cache, but they are separate systems and cannot succeed or fail simultaneously, creating a time window. Concurrent reads and writes can then see stale data. Distributed transactions could theoretically guarantee atomicity but are rarely used in practice.

The goal is to minimize the inconsistency window and impact, achieving eventual consistency.

Four Cache Update Design Patterns

2.1 Delete Cache First, Then Update Database (Not Recommended)

This pattern easily produces long-lived dirty data under concurrency.

Execution flow:

Client 1 triggers update of data A.

Client 2 triggers query of data A.

Client 1 deletes data A from cache.

Client 2 queries cache for data A, misses.

Client 2 queries database for data A (old value) and writes it to cache.

Client 1 updates database with new value for data A.

Result: cache holds old value while database has new value — inconsistency persists until next update.

2.2 Update Database First, Then Invalidate Cache (Cache Aside Pattern)

May cause short-lived inconsistency but probability is low; acceptable for most businesses.

Execution flow:

Client 1 triggers update of data A.

Client 2 triggers query of data A.

Client 3 triggers query of data A.

Client 1 updates database with new value for data A.

Client 2 queries cache, hits and returns old value.

Client 1 invalidates cache entry for data A.

Client 3 queries cache, misses.

Client 3 queries database, gets new value, writes to cache.

Result: cache and database eventually consistent; only Client 2 saw stale data briefly.

2.3 Update Cache Only, Cache Synchronously Updates Database (Read/Write Through Pattern)

Business logic only updates cache; cache synchronously writes to database. Inconsistency probability is extremely low but requires custom cache implementation.

Execution flow:

Client 1 triggers update of data A.

Client 2 triggers query of data A.

Client 1 updates cache for data A; cache synchronously updates database, then returns.

Client 2 queries cache, hits and returns new value.

Read Through works similarly: on cache miss, cache fetches from database, stores, then returns.

2.4 Update Cache Only, Cache Asynchronously Updates Database (Write Behind Cache Pattern)

Best read/write performance (only memory operation before returning), but non-strong consistency; data loss possible if cache fails before flushing.

Execution flow:

Client 1 triggers update of data A.

Client 2 triggers query of data A.

Client 1 updates cache for data A, returns immediately.

Client 2 queries cache, hits and returns new value.

Cache asynchronously updates data A to database.

Risk: if cache crashes before async flush, the update is lost.

Summary

All four patterns are distilled from prior experience; each has drawbacks and none is perfect. In system design, do not chase perfection — make trade-offs and pick the pattern that best fits your business scenario.

Source: 追光者 Link: developer.jdcloud.com/article/2776

Code example

·················END·················
资料链接
清华学姐自学的Linux笔记，天花板级别！
新版鸟哥Linux私房菜资料
阿里大佬总结的《图解Java》火了，完整版PDF开放下载！
Alibaba官方上线！SpringBoot+SpringCloud全彩指南
国内最强的SpringBoot+Vue全栈项目天花板，不接受反驳！