Redis：缓存问题之数据不一致（更新数据库时 主动更新）

Redis：缓存问题之数据不一致（更新数据库时 主动更新）

---

关键词

• 数据源不一样（缓存和db操作非原子性）
• 1.延时双删 —> 2.TTL —> 3.缓存删除失败记录到日志中，利用脚本提取失败记录再次删除

一、不一致问题

缓存和DB的数据不一致的根源 ： 数据源不一样

二、不一致分析

2.1 分析

• 强一致性很难，追求最终一致性（时间）

• 互联网业务数据处理的特点
  高吞吐量
  低延迟
  数据敏感性低于金融业

• 时序控制是否可行？
  先更新数据库再更新缓存或者先更新缓存再更新数据库
  本质上不是一个原子操作，所以时序控制不可行
  高并发情况下会产生不一致

三、不一致解决（延时双删）

1、（第一次删除：）先更新数据库同时删除缓存项(key)，等读的时候再填充缓存
2、（第二次删除：避免并发读）2秒后再删除一次缓存项(key)（理论上，2s之后db的操作肯定已经commit了）
3、（第二次删除失败，配置TTL）设置缓存过期时间 Expired Time 比如 10秒 或1小时
4、将缓存删除失败记录到日志中，利用脚本提取失败记录再次删除（缓存失效期过长 7*24）

升级方案

（异步，滞后）通过数据库的binlog来异步淘汰key，利用工具(canal)将binlog日志采集发送到MQ中，然后通过ACK机制确认处理删除缓存

四、缓存与数据库一致性

4.1 缓存更新策略

• 利用Redis的缓存淘汰策略被动更新 LRU 、LFU
• 利用TTL被动更新
• 在更新数据库时主动更新 （先更数据库再删缓存----延时双删）
• 异步更新 定时任务 数据不保证时时一致 不穿DB（直接client访问redis，不走db；db定时更新redis）

4.2 不同策略之间的优缺点

策略	一致性	维护成本
利用Redis的缓存淘汰策略被动更新	最差	最低
利用TTL被动更新	较差	较低
在更新数据库时主动更新	较强	最高