网站制作要学哪些最新的疫情数据
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