缓存策略及一致性保障方案
2023-10-22 14:24:18 1 举报AI智能生成
登录查看完整内容
缓存策略及一致性保障方案
作者其他创作
大纲/内容
浪费空间
和db数据不一致
设置为null
误判率
无法删除元素
布隆过滤器
不存在的数据
穿透
永不过期+ 定时任务
设置过期+ 定时任务 定时更新缓存时间
热点数据
击穿
打散
大量过期
雪崩
过期时间、策略
先读，缓存没有则查DB，然后有数据就更新到缓存
读
先写DB，然后更新/删除缓存
写
是什么
性能：如果需要复杂计算才更新缓存，那直接删除可以减少不必要的计算。（因为有冷数据）
安全：更新容易带来不一致。在AB都更新DB，结果BA更新缓存场景
对比 更新还是删除好
不行，A是写操作，结果A删了缓存还没更新时，B查来了，在A还没更新完的时候，先查DB把旧值缓存起来了
能不能先删缓存
一致性分析
为什么要这样
大部分场景，对缓存的一致性要求一般，不是非常高的时候。
适用场景
缓存重试
缓存时间
重试队列
数据变更，由定时任务定时将新更新的同步到缓存
延时双删
补偿方案
cache Aside
读控制层，读没有就返回。由控制层进行如果没有，则取查库然后返回到缓存等。
Read Through
先访问控制层，由控制层进行更新DB 和缓存。放在事务里。
write Thorugh
写比较多，对一致性要求比较高的
使用场景
加锁
锁的超时时间
请求暂存在消息队列中顺序消费。
队列
结合Read/ write Through
数据库里 innodb是这么做的
异步回写
但需要做缓存的高可用
电商秒杀场景中库存的扣减
写请求延迟较低，减轻了数据库的压力，具有较好的吞吐性
一致性较弱
适用场景 /写多
writh Behind
cache Aside (更新缓存) + 重试+ 定时任务校验/更新缓存 + 永久缓存（高并发 防止缓存雪崩）
实际案例
策略
缓存策略及一致性保障方案
0 条评论
回复 删除
下一页
