上海网站seoseodian,作业网站的设计制作案例,如何做淘外网站推广,百度竞价代运营外包场景1#xff1a;秒杀库存场景#xff0c; 10000人抢100个商品
如果用普通的分布式锁实现#xff0c; 最后抢到的人#xff0c;要等前面99个人抢完
优化方案#xff1a;可用分段锁#xff0c; 降低锁的粒度#xff0c; 比如1-10库存用锁product:101_1,11-20库存用锁pr…场景1秒杀库存场景 10000人抢100个商品
如果用普通的分布式锁实现 最后抢到的人要等前面99个人抢完
优化方案可用分段锁 降低锁的粒度 比如1-10库存用锁product:101_1,11-20库存用锁product:101_2等 提高并发性能
代码 场景2: 商品的增删改查
查询先从缓存获取缓存没有查库 查到库之后放入缓存
新增/修改取数据库更新货品删除缓存 问题199%的商品都是冷门商品 不应该全部放在redis缓存
解决设置缓存有效期 例如一天每次查询时将锁延期ttl命令很快 实现冷热数据分离。如果每天访问的热数据还是很多 可以用缓存淘汰策略。 问题2 缓存击穿。例如某些批量操作 批量查库 批量放缓存一天 缓存同时过期 下次批量操作时 大量请求直接打到数据库数据库顶多只能扛几万的qps
解决缓存过期时间加上随机数 分散过期 分散查库压力 问题3 缓存穿透。
例如某个热门商品被后台小二误删 客户端还有很多人访问会有大量请求持续打到数据库
例如黑客攻击浏览器编辑url访问一个不存在的商品id
解决
将不存在商品缓存NULL, 下次直接从缓存拿布隆过滤器 问题4黑客用脚本批量访问很多不存在的商品id导致Redis缓存很多不存在的值是NULL商品
解决NULL商品缓存有效期可以设置短一点 例如1分钟 问题5: 热点key重建
前提:
当前key是一个热点key例如一个热门的娱乐新闻并发量非常大。重建缓存不能在短时间完成 可能是一个复杂计算 例如复杂的SQL、 多次IO、 多个依赖
缓存失效的瞬间 会有大量线程来重建缓存 造成后端负载加大 可能会让应用崩溃
解决: 分布式锁双重检查.查数据库之前加一把分布式锁, 获取锁成功后, 再去缓存检查一遍, 缓存没有再去查库. 问题6: 缓存雪崩
如果发生以下场景, 导致大量请求直接打到数据库, 引起系统负载暴增, 性能下降甚至瘫痪
在某个时间点缓存中的大量数据同时过期失效。Redis宕机
解决:
限流缓存加随机时间用多级缓存, 例如再加一层JVM缓存,encache设置过期时间, mq广播更新本地缓存热点缓存系统, 客户端只查JVM缓存, 服务端更新JVM缓存 问题7: 缓存双写不一致
1. 双写不一致 2. 读写不一致 线程3如果在查数据库和写缓存中间卡顿, 如果这时候线程2写数据, 线程3再去更新缓存, 就会缓存脏数据.
解决:
读多写少时候, 用redisson读写锁, 读写互斥, 读读不互斥读多写多时候, 不建议用缓存 大纲 ReadLock解决以及缺陷 主从同步 持久化 减库存场景 分段锁降低锁粒度 冷热数据分离 查数据时,锁延期 缓存击穿,缓存穿透 随机时间, 缓存NULL(NULL过期时间不用太长), 布隆过滤器 冷门数据突变成热点数据问题 分布式锁 双重检查 缓存数据双写不一致问题 读多写少 加读写锁(Redisson_WriteReadLock) 部分场景tryLock代替lock 串行转并行 Redis雪崩 大V发热点新闻 大量请求同时访问Redis 1. 限流 2. 多级缓存(加一层JVM缓存),encache设置过期时间, mq广播更新本地缓存 3. 热点缓存系统, 客户端只查JVM缓存, 服务端更新JVM缓存
