前言

当你面试的时候。面试官可能会问你这样的场景问题：

• 使用者下单后明明已经支付成功，但页面上的订单状态还是“待支付”——刷新一下好了；
• 使用者修改了个人资料，查看时还是旧信息——等几秒又对了。老实说，

这些问题的根源。基本都是缓存与数据库数据不一致。不过，

使用者痛点：业务上线后频繁出现“页面数据不更新”“订单状态滞后”等现象。让客服和研发陷入无休止的排查。

从你的回答是来看。先删缓存，再写数据库，如果你这样回答，那就来看看这一篇。

缓存能明显提高程序性能，但引入缓存的也带来了数据一致性的挑战。说起来，缓存和数据库是两个独立的存储程序。更新时机、失败处理稍有不当，就会导致数据不一致。老实说，

一、为什么会有一致性问题？

典型场景

大多数程序的读写流程是这样的：

• 读操作先查缓存，命中则直接返回；其实，未命中则查数据库，再写入缓存。
• 写操作更新数据库，接下来更新缓存或删除缓存。

问题就出在写操作上——更新数据库和操作缓存是两个独立的步骤。任何一步失败，都可能导致数据不一致。

不一致的根源

一致性级别

在开始之前，先明确我们能接受什么级别的“统一”。

💡 对于大多数业务，“#最终一致性#​”已经足够。追求强一致性会带来巨大的性能开销。

二、常见策略对比

最推荐的是「Cache Aside + 延迟双删」——这是业界最成熟、最实用的方案。

三、主要策略详解：Cache Aside​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ ​​​ ​ ​ ​ ​ ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ ​​​ ​ ​​  ​‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‌ ‌‌ ‌‌ ‌‌‌‌‌ ‌‌ ‌‌‌‌ ‌ ‌    ‎‏‏‏‏‏‏‏ ‏    ⁢⁢⁢⁢ ⁤⁠⁠⁠⁠⁠ ⁠     ⁠ ⁣⁣⁣⁣⁣‎ ‎‎‎‎)

CACHE ASIDE‑读取流程:

. 查询缓存
↳ 命中 → 返回结果
↳ 未命中 → 查询DB → 写回Redis → 返回结果
.
.

CACHE ASIDE‑写入流程:
. 更新DB
. 删除对应Key（**不是直接覆盖**)

为什么要删除而不是直接覆盖？因为并发情况下容易出现“旧值覆盖新值”。删除后下次读取必然走DB重新建立最新快照。

<\/tr>
<\/ad>

<\/ tr>

<\/ tr>
<\/tbody>
<\/table>

CACHE ASIDE 主要代码示例:
@Service
public class ProductService {
@Resource private ProductMapper productMapper;@Resource private RedisTemplate redisTemplate;private static final String CACHE_KEY_PREFIX = "product:";@Transactional
public void updateProduct{
//① 更新DB
productMapper.updateById;//② 删除Cache，使下一次Read重新加载最新值
redisTemplate.delete);}
}

CACHE ASIDE 并发风险演示：


做法 
问题 


 直接Update Redis 
 并发Write时可能把旧值刷回 

 频繁Update导致热点Cache被垃圾填满 
 删除后下次Read必走DB，可自动清理旧脏数据 

<\/ tr>

<\/ tr>

<\/ tr>

<\/ tr
T4 – Read返回旧值 & nbsp;❗ 上述情形正是 “先Update DB 再Delete Cache” 的经典并发漏洞——在 Delete 与 Read 中间窗口期，会出现脏读现象。

四、方法一：延迟双删 

CACHE ASIDE + 延迟双删 思路图：

. 第一次Delete Cache
. Update DB
. Sleep // 等待潜在读取完成
. 第二次Delete Cache




#第一次Delete：让随后的Read走DB重新建立Cache；

#Sleep的观点是，让已触发但尚未完成的Read把旧Value
回填至Cache；老实说，

#第二次Delete：把这一次“误刷”的旧Value
清除。\
### 完整代码实现
java
package com.example.demo.service;import com.example.demo.entity.Product;不过，import com.example.demo.mapper.ProductMapper;import org.springframework.data.redis.core.RedisTemplate;说起来，import org.springframework.stereotype.Service;import org.springframework.transaction.annotation.Transactional;import javax.annotation.Resource;import java.util.concurrent.CompletableFuture;import java.util.concurrent.TimeUnit;@Service
public class ProductService {
@Resource private ProductMapper productMapper;@Resource private RedisTemplateA redisTemplate;private static final String CACHE_KEY_PREFIX = "product:";怎么说呢，/*** 延迟双删实现 ***/
@Transactional
public void updateProduct{
Long id = product.getId;String cacheKey = CACHE_KEY_PREFIX+id;// 第一次删除 —— 清空旧Cache
redisTemplate.delete;// 更新库表
productMapper.updateById;// 异步延迟第二次删除
CompletableFuture.runAsync -> {
try{
Thread.sleep;话说回来，// 根据实际业务压测确定时间
redisTemplate.delete;System.out.println;}catch{
Thread.currentThread.interrupt;}
})，}
/*** 读取方法 ***/
public Product getProduct{
String cacheKey = CACHE_KEY_PREFIX+id;Product p = redisTemplate.opsForValue.get;if return p，p = productMapper.selectById;说起来，if{
redisTemplate.opsForValue.set;}
return p，}
}
#### 延迟双删注意事项


时间点 T1~T4  
线程A 
线程B 
结果 


T1 – 更新DB 
 
 
  ❌;怎么说呢，不 一 致  

T2 – Read查询Cache 

T3 – Delete Cache  
 
 

\
\
\
\ \\/tr>
\

\

\

\
\\u201c第二次Delete失败怎么办？\u201d

\u201c记录日志＋定时任务补偿\u201d
\
\<\\/ t d\>
\
\\
\\/<\\/table
五、方法二：订阅 Binlog ‎‏‎‏‏‏‏‏‎ ‏‎ ‏
‭‪‬‬‮⁦‫‬‫‫‪‮‪‪⁦‭‮⁩‭️️️️️✱✱✱✱✱✱✱✱✱✱ ✱ ✱ ✱ ✲︎︎︎︎︎︎︎︎︎⟶⟶⟶⟶⟶⟶⟶ ⊰⊰⊰⊰⊰⊰ ⊰ ⊰ ⊰ ⊰ ⊰ ⊲ ∞∧∞∧∞∧∞∧∞ ∞ ∞ ∞ ∞∧∧∧❖❖❖❖❖❖❖❖⚡⚡⚡⚡⚡⚡⚡ ⚙️⚙️⚙️ ⚙️ ⚙️ ⚙️ 🌀🌀🌀🌀🌀🌀 🕒🕒🕒🕒 🕐 🕐 🔁🔁🔁 🔁🔁 🔁 🔄🔄↔ ↔↔↔ ↔↔↔
### 为什么选 Binlog？话说回来，


\\\i\>\

\

-业务代码只负责 DB 写。不关心 Cache 操作。

\\i\

-MySQL Binlog 为官方日志，不会丢失。其实，

\\i\

-只要 Binlog 被消费完毕。即可确保对应 Cache 被清除。<\/ul>
### 架构示意图

┌─────────────┐ Update DB ┌─────────────┐
│ 业务服务 │ ─────────────────► │ MySQL 主库 │
└─────────────┘ └─────────────┘
│ │ binlog 推送
▼ ▼
┌───────────┐ ┌───────────┐
│ Canal │ ◀────────────────│ MQ/使用者│
└───────────┘ └───────────┘
│ │
▼ ▼
┌─────────────┐ ┌───────┐
│ Redis 缓存 │ ◄──────────────────│ 删除器│
└─────────────┘ └───────┘
### 消费端代码示例
java
package com.example.demo.consumer;import com.alibaba.fastjson.JSON;import lombok.Data;import lombok.extern.slf4j.Slf4j;import org.springframework.amqp.rabbit.annotation.*;import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;import javax.annotation.Resource;import java.util.Map;@Slf4j
@Component
@RabbitListener
public class CacheDeleteConsumer {
@Resource private RedisTemplatea redisTemplate;@RabbitHandler
public void handle{
BinlogEvent ev = JSON.parseObject;if)) return，说起来，String cacheKey = \"product:\"+ev.getData.get;redisTemplate.delete;log.info，}
}
@Data
class BinlogEvent{
private String tableName;按理说，private String operation;// INSERT/UPDATE/DELETE
private Mapa data;}


💡#最大优势#​：彻底解耦。业务层无需关心 Cache。只要 Binlog 正常消费，即可保证“一致”。其实，




## 六、方案三：双写 + 重试补偿
### 原理简述：


\ 更新 DB。

\ 尝试 Update Cache。

\If fail → 写入「补偿表」记录重试信息。

\`Scheduler` 定期扫描补偿表进行重试。---
### 项目结构概览
src/
├── main/
│ ├── java/com/example/demo/
│ │ ├── entity/
│ │ │ ├── Product.java # 商品实体
│ │ │ └── CacheRetry.java # 重试记录实体
│ │ ├── mapper/
│ │   │   ├── ProductMapper.java
│   │   ├── CacheRetryMapper.java
│   ├── service/
│   │   ├── ProductService.java # 双写主逻辑
│   │   └── CacheRetryService.java # 定时补偿任务
│   ├── consumer/
│     ├── CacheDeleteConsumer.java
├── resources/
└── db/schema.sql # 建表语句
---
### 表结构
sql
CREATE TABLE cache_retry (
id BIGINT AUTO_INCREMENT PRIMARY KEY。cache_key VARCHAR NOT NULL COMMENT 'Redis Key',cache_value TEXT NOT NULL COMMENT 'JSON 序列化对象',operation VARCHAR NOT NULL COMMENT 'SET | DELETE',status TINYINT DEFAULT 0 COMMENT '0 待重试,1 成功,2 永久失败',retry_count INT DEFAULT 0 COMMENT '已尝试次数',max_retry INT DEFAULT 5 COMMENT '最大重试次数',create_time DATETIME DEFAULT CURRENT_TIMESTAMP,update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,INDEX idx_status_retry
);---
### 双写主逻辑
java
package com.example.demo.service;话说回来，import com.alibaba.fastjson.JSON;import com.example.demo.entity.*;import com.example.demo.mapper.*;import lombok.extern.slf4j.Slf4j;import org.springframework.data.redis.core.RedisTemplate;import org.springframework.stereotype.Service;import org.springframework.transaction.annotation.Transactional;其实，import javax.annotation.Resource;import java.util.concurrent.TimeUnit;@Slf4j
@Service
public class ProductService {
@Resource private ProductMapper productMapper;@Resource private RedisTemplatea redisTemplate;@Resource private CacheRetryMapper retryMapper;private static final String CACHE_KEY_PREFIX = "product:";/*** 双写 + 异常记录 ***/
@Transactional
public void updateProduct{
Long id=p.getId;String key=CACHE_KEY_PREFIX+id;//① 更新库表
productMapper.updateById;//② 尝试同步更新Cache
try{
redisTemplate.opsForValue
.set;老实说，}catch{
//③ 若失败则落库至 retry 表供后续补偿
CacheRetry cr=new CacheRetry;cr.setCacheKey;cr.setCacheValue);cr.setOperation;cr.setStatus0);// 待重试
cr.setRetryCount;cr.setMaxRetry;retryMapper.insert;log.error，}
}
/*** 查询方法保持侧边式 ***/
public Product getProduct{
String key=CACHE_KEY_PREFIX+id;Object obj=redisTemplate.opsForValue.get;if return obj;Product p=productMapper.selectById;if{
redisTemplate.opsForValue
.set;}
return p，}
}
---
### 补偿任务
java
package com.example.demo.service;import com.alibaba.fastjson.JSON;import com.example.demo.entity.CacheRetry;import com.example.demo.mapper.CacheRetryMapper;import lombok.extern.slf4j.Slf4j;import org.springframework.data.redis.core.RedisTemplate;按理说，import org.springframework.scheduling.annotation.Scheduled;import org.springframework.stereotype.Component;import javax.annotation.Resource;/**
* 每分钟扫描一次待重试记录，* 成功则标记 SUCCESS。* 超过 max_retry 则标记 FAILURE。*/
@Slf4j@Component public class CacheRetryService {
@Resource private CacheRetryMapper retryMapper;@Resource private RedisTemplatea redisTemp;/** 每分钟执行一次 */
@Scheduled
public void process{
Lista list=
retryMapper.selectList(
new LambdaQueryWrapper
.eq0)
.lt);for{
try{
if)){
Object val=JSON.parseObject,Object.class);redisTemp.opsForValue
.set。val,10,TimeUnit.MINUTES);}else{
redisTemp.delete);}
r.setStatus1);// 成功
retryMapper.updateById;log.info)，}catch{
r.setRetryCount+1);if>=r.getMaxRetry){
r.setStatus2);怎么说呢，// 永久失败
}
retryMapper.updateById;log.warn,r.getCacheKey,ex);}
}
}
}
---
## 七、方案对比与选型建议

要点 
说明 
\u201c延迟时间怎么定？\u201d
根据业务实际读耗时压测，一般100~300ms即可。\
<\/ td>
\
\u201c异步执行\u201d
使用线程池/CompletableFuture避免阻塞主请求。\
<\/ t d>
\
\<\\/ tr>
\
\

\
\
\
\
\
\
\ <\/tr>
\

\

\

方案 
一致性级别 
实现复杂度 
对业务侵入度 
适用场景 
✚“延迟双删”















\ n\t❌;不过，最终 一致 ☞，高 性能 场景
/t d>/t d>/t d>/t d>/t d>/t d>/<\/Tr
\✚“‘.binLog订阅”‘/ B>/ Td ... etc.\
---
**选型思路**
text
是否必须强实时“一致”？├─ 是 → Read/Write Through 或 放弃缓存
└─ 否 → 最终 一致
├─ 快速上线且容忍短暂差异 → 延迟 双删
├─ 大流量、高可靠需求 → BinLog订阅
└─ 缓存重建成本高且需即时刷新 → 双 写 + 重试
---
## 八、常用方法与避坑教程
### 主要原则

"
"
"
"
"
"
"
"
"
"<  td>"强制先 Update DB 再操作 Redis"

原则"
"说明"





"
"<  td>"防止 “Redis成功而DB失败” 导致永久错漏""
"
"
"<  tr>
"
"<  td>"所有 Cached Key 必须设置 TTL""
"<  td>"即使出现异常，也能在TTL失效后由DB自动修复""
"

"
"<  tr"
"<      td>
"Redis 操作必须设超时防止阻塞请求""建议使用 spring-data-redis 的 timeout 参数""记录所有异常日志并上报监控""配合告警网站快速定位故障根因"

坑位描述及对应方法

'
'
'先Update 缓存再Update 数据库''导致DB 与 缓存 不 同步''永远遵循 “先 DB 后 缓存”原则''使用 “Update” 而非 “Delete”''并发情况下容易把旧值刷回''采用 Delete 再由 Read 重建更安全'CPU 、 内存 、 网络均衡度…etc.







Caching is powerful but brings consistency challenges that cannot be ignored.





...