如果用普通的分布式锁实现， 最后抢到的人，要等前面99个人抢完
优化方案：可用分段锁， 降低锁的粒度， 比如1-10库存用锁product:101_1,11-20库存用锁product:101_2等， 提高并发性能
代码：==
场景2: 商品的增删改查,如何用高并发缓存架构实现?针对各种并发场景,如何优化
问题1：99%的商品都是冷门商品， 不应该全部放在redis缓存
解决：设置缓存有效期， 例如一天，每次查询时将锁延期（ttl命令很快）， 实现冷热数据分离。如果每天访问的热数据还是很多， 可以用缓存淘汰策略。
问题2： 缓存击穿。例如某些批量操作， 批量查库， 批量放缓存一天， 缓存同时过期， 下次批量操作时， 大量请求直接打到数据库，数据库顶多只能扛几万的qps
例如某个热门商品被后台小二误删， 客户端还有很多人访问，会有大量请求持续打到数据库；
解决：
问题4：黑客用脚本批量访问很多不存在的商品id，导致Redis缓存很多不存在的值是NULL商品
前提:
缓存失效的瞬间， 会有大量线程来重建缓存， 造成后端负载加大， 可能会让应用崩溃
解决: 分布式锁+双重检查.查数据库之前加一把分布式锁, 获取锁成功后, 再去缓存检查一遍, 缓存没有再去查库.
如果发生以下场景, 导致大量请求直接打到数据库, 引起系统负载暴增, 性能下降甚至瘫痪
解决:
问题7: 缓存双写不一致
1. 双写不一致
2. 读写不一致
线程3如果在查数据库和写缓存中间卡顿, 如果这时候线程2写数据, 线程3再去更新缓存, 就会缓存脏数据.
解决:
解决: 如果确定重建缓存大概需要的时候, 可用tryLock代替lock, 串行转并发.但是要考虑tryLock失败问题, 比如递归重新查或者返回错误码友好提示.
代码: ==
原文地址:https://blog.csdn.net/weixin_64027360/article/details/134725410
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_25828.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
