这篇文章主要介绍“如何解决秒杀系统挂了的问题”，在日常操作中，相信很多人在如何解决秒杀系统挂了的问题问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何解决秒杀系统挂了的问题”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
什么原因造成的?
抢购活动计划是零点准时开始：
22：00，运营人员通过后台将商品上线。
23：00，后台小哥已经将商品导入缓存中，提前预热。
抢购开始的瞬间流量非常大，按计划是通过 Redis 承担大部分用户查询请求，避免请求全部落在数据库上。
缓存命中
如上图预期大部分请求会命中缓存，但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为 2 小时过期。
因此所有的商品在同一个时间点全部失效，瞬间所有的请求都落在数据库上，导致数据库扛不住压力崩溃，用户所有的请求都超时报错。
实际上所有的请求都直接落到数据库，如下图：
缓存雪崩
什么时候发现的?
凌晨 01：02，SRE 收到系统告警，登录运维管理系统发现数据库节点 CPU 和内存飙升超过阈值，迅速联系后台开发人员定位排查。
为什么没有早点发现?
由于缓存设置过期时间是 2 小时，凌晨 1 点前缓存可以命中大部分请求，数据库服务处于正常状态。
发现时采取了什么措施?
后台小哥通过日志定位排查发现问题后，进行了一系列操作：
首先通过 API Gateway(网关)限制大部分流量进来。
接着将宕机的数据库服务重启。
再重新预热缓存。
确认缓存和数据库服务正常后将网关流量正常放开，大约 01：30 抢购活动恢复正常。
如何避免下次出现?
这次事故的原因其实就是出现了缓存雪崩，查询数据量巨大，请求直接落到数据库上，引起数据库压力过大宕机。
在业界解决缓存雪崩的方法其实比较成熟了，比如有：
均匀过期
加互斥锁
缓存永不过期
均匀过期
设置不同的过期时间，让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。
缓存 key 过期时间均匀分布
加互斥锁
跟缓存击穿解决思路一致，同一时间只让一个线程构建缓存，其他线程阻塞排队。
互斥访问
缓存永不过期
跟缓存击穿解决思路一致，缓存在物理上永远不过期，用一个异步的线程更新缓存。
异步更新缓存
到此，关于“如何解决秒杀系统挂了的问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
