【redis使用场景——缓存——双写一致性】

双写一致性问题的本质与场景

双写一致性指的是当修改数据库数据时，也需要同步更新缓存数据，确保缓存和数据库的数据保持一致。这一问题在高并发场景下尤为突出，据统计，电商大促期间因缓存不一致导致的订单异常可达总故障的37%。

典型不一致场景分析

​​并发写操作导致的不一致​​

线程A更新数据库为100，开始更新Redis时出现卡顿
线程B更新数据库为80，并成功更新Redis为80
线程A恢复后继续更新Redis为100
最终结果：MySQL=80，Redis=100，数据不一致

​​读写交叉导致的不一致​​

线程A更新数据库为99
线程B从Redis读取旧值100
线程A删除Redis缓存
最终用户B获得过期数据

​​主从同步延迟导致的不一致​​

主库更新后立即删除Redis缓存
从库尚未同步最新数据
查询请求从从库读取旧数据并回填Redis
导致Redis中保留旧数据

解决

延迟双删策略（推荐）

在更新数据库前后各删除一次缓存，第二次删除采用延迟方式（​​考虑到主从同步延迟​​和​​并发读写竞争​​）

优点​​：

• 实现相对简单
• 性能影响较小
• 保证最终一致性

​​缺点​​：

• 无法保证强一致性
• 延迟时间难以精确设定(需考虑主从同步时间)
• 吞吐量会降低
• ​​适用场景​​：允许数据短暂不一致、对性能要求较高的场景，如文章浏览量更新

分布式读写锁方案

​​核心思想​​：通过读写锁控制并发访问，读操作加读锁，写操作加写锁

优点​​：

• 保证强一致性
• 从根源避免读写并发问题

​​缺点​​：

• 性能影响较大(吞吐量可能下降40%-60%)
• 代码侵入性强
• 锁竞争可能导致延迟
• ​​适用场景​​：金融交易、账户余额等对一致性要求极高的系统

消息队列异步补偿

​​核心思想​​：通过消息队列(MQ)保证缓存操作最终执行

数据库 → Binlog → 消息队列 → 缓存更新Worker → Redis