秒杀系统挂了,凌晨1点紧急救场!
公司最近安排了一波商品抢购活动,由于后台小哥操作失误最终导致活动效果差,被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。
图片来自 Pexels
什么原因造成的?
抢购活动计划是零点准时开始:
22:00,运营人员通过后台将商品上线。
23:00,后台小哥已经将商品导入缓存中,提前预热。
抢购开始的瞬间流量非常大,按计划是通过 Redis 承担大部分用户查询请求,避免请求全部落在数据库上。
如上图预期大部分请求会命中缓存,但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为 2 小时过期。
因此所有的商品在同一个时间点全部失效,瞬间所有的请求都落在数据库上,导致数据库扛不住压力崩溃,用户所有的请求都超时报错。
什么时候发现的?
凌晨 01:02,SRE 收到系统告警,登录运维管理系统发现数据库节点 CPU 和内存飙升超过阈值,迅速联系后台开发人员定位排查。
为什么没有早点发现?
由于缓存设置过期时间是 2 小时,凌晨 1 点前缓存可以命中大部分请求,数据库服务处于正常状态。
发现时采取了什么措施?
后台小哥通过日志定位排查发现问题后,进行了一系列操作:
首先通过 API Gateway(网关)限制大部分流量进来。
接着将宕机的数据库服务重启。
再重新预热缓存。
确认缓存和数据库服务正常后将网关流量正常放开,大约 01:30 抢购活动恢复正常。
如何避免下次出现?
这次事故的原因其实就是出现了缓存雪崩,查询数据量巨大,请求直接落到数据库上,引起数据库压力过大宕机。
在业界解决缓存雪崩的方法其实比较成熟了,比如有:
均匀过期
加互斥锁
缓存永不过期
均匀过期
加互斥锁
缓存永不过期
复盘总结
通过与同事复盘这次线上事故,大家对于缓存雪崩有了更深刻的理解。
为了避免再次出现缓存雪崩事故,大家一起讨论了多个解决方案:
均匀过期
加互斥锁
缓存永不过期
希望技术人能够敬畏每一行代码!
编辑:陶家龙
精彩文章推荐: