秒杀系统挂了,凌晨1点紧急救场!

开发 架构 开发工具
公司最近安排了一波商品抢购活动,由于后台小哥操作失误最终导致活动效果差,被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。

公司最近安排了一波商品抢购活动,由于后台小哥操作失误最终导致活动效果差,被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。

[[351568]] 

图片来自 Pexels

什么原因造成的?

抢购活动计划是零点准时开始:

  • 22:00,运营人员通过后台将商品上线。
  • 23:00,后台小哥已经将商品导入缓存中,提前预热。

抢购开始的瞬间流量非常大,按计划是通过 Redis 承担大部分用户查询请求,避免请求全部落在数据库上。

缓存命中

如上图预期大部分请求会命中缓存,但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为 2 小时过期。

因此所有的商品在同一个时间点全部失效,瞬间所有的请求都落在数据库上,导致数据库扛不住压力崩溃,用户所有的请求都超时报错。

实际上所有的请求都直接落到数据库,如下图:

缓存雪崩

什么时候发现的?

凌晨 01:02,SRE 收到系统告警,登录运维管理系统发现数据库节点 CPU 和内存飙升超过阈值,迅速联系后台开发人员定位排查。

为什么没有早点发现?

由于缓存设置过期时间是 2 小时,凌晨 1 点前缓存可以命中大部分请求,数据库服务处于正常状态。

发现时采取了什么措施?

后台小哥通过日志定位排查发现问题后,进行了一系列操作:

  • 首先通过 API Gateway(网关)限制大部分流量进来。
  • 接着将宕机的数据库服务重启。
  • 再重新预热缓存。
  • 确认缓存和数据库服务正常后将网关流量正常放开,大约 01:30 抢购活动恢复正常。

如何避免下次出现?

这次事故的原因其实就是出现了缓存雪崩,查询数据量巨大,请求直接落到数据库上,引起数据库压力过大宕机。

在业界解决缓存雪崩的方法其实比较成熟了,比如有:

  • 均匀过期
  • 加互斥锁
  • 缓存永不过期

均匀过期

设置不同的过期时间,让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。

缓存 key 过期时间均匀分布

加互斥锁

跟缓存击穿解决思路一致,同一时间只让一个线程构建缓存,其他线程阻塞排队。

互斥访问

缓存永不过期

跟缓存击穿解决思路一致,缓存在物理上永远不过期,用一个异步的线程更新缓存。

异步更新缓存

复盘总结

通过与同事复盘这次线上事故,大家对于缓存雪崩有了更深刻的理解。

为了避免再次出现缓存雪崩事故,大家一起讨论了多个解决方案:

  • 均匀过期
  • 加互斥锁
  • 缓存永不过期

希望技术人能够敬畏每一行代码!

作者:雷架,华中科技大学硕士毕业;浪过几个大厂:华为、网易、百度……

编辑:陶家龙

出处:转载自公众号爱笑的架构师(ID:DancingOnYourCode)

 

责任编辑:武晓燕 来源: 爱笑的架构师
相关推荐

2020-12-02 06:14:35

秒杀系统

2018-03-14 09:02:42

2019-05-17 15:35:28

PNG数据结构

2017-09-20 07:13:28

苹果iOS

2019-07-22 09:10:23

PhotshopPNGPNG类型

2019-08-05 10:15:33

系统缓存架构

2018-04-04 09:57:25

2021-08-09 08:24:08

时间工作生活

2019-07-23 13:32:13

Java开发代码

2020-10-14 07:20:53

高并发

2013-02-16 13:26:00

360急救盘数据安全360安全中心

2021-05-25 06:53:06

iOS 15 App 苹果

2018-11-08 15:10:02

阿里双十一架构

2010-08-13 10:11:46

CISCO路由器备份

2010-08-04 10:08:24

路由器配置

2018-09-15 04:59:01

2019-07-31 10:08:19

人工多线程数据

2014-01-17 14:08:45

移动os国产软件

2022-08-26 10:24:48

架构Golang

2018-06-04 09:47:27

加班焦虑互联网
点赞
收藏

51CTO技术栈公众号