经理要求我审查上一次Redis缓存雪崩事故。

时间:2022-12-10

事故的背景公司最近安排了一波商品购买活动。

由于后台兄弟的操作错误,活动结果很差,遭到用户和代理商的抱怨。

经理要我带我的同事来回顾在线事故。

是什么原因造成的?抢购活动计划按时从0:00开始,到22:00,操作人员将在23:00通过后台将产品上线。

后端兄弟已将产品导入缓存。

预热和急冲的瞬间流量非常大。

根据计划,Redis将承担其中的大部分。

用户查询请求,以避免所有请求落在数据库上。

高速缓存命中如上图所示,大多数请求都将命中高速缓存,但是由于后台兄弟会预热高速缓存,因此所有产品的高速缓存时间都设置为2小时以到期,并且所有产品都将在此时间失效。

同一时间点,所有请求都是瞬时的。

所有数据均落在数据库上,导致数据库在压力下崩溃,所有用户请求均超时,并报告了错误。

实际上,所有请求都直接落入数据库,如下图所示:何时发现缓存雪崩?凌晨01:02,SRE收到系统警报,登录到运维管理系统,发现数据库节点的CPU和内存已飙升至阈值以上,并迅速联系后台开发人员进行定位和故障排除。

您为什么不早发现?由于高速缓存设置的到期时间为2小时,因此高速缓存可以在凌晨1点之前命中大多数请求,并且数据库服务处于正常状态。

发现时采取了什么措施?在通过日志定位和故障排除发现问题之后,后台兄弟执行了一系列操作:首先,限制大部分流量通过API网关(网关)进入,然后重新启动关闭的数据库服务,然后重新加热缓存。

确认缓存和数据库服务正常后,网关流量已正常释放,并且紧急购买活动在01:30左右恢复正常。

如何避免下次出现?事故的原因实际上是缓存雪崩,大量查询数据以及请求直接落在数据库上,导致数据库处于压力和停机时间。

在业界,解决高速缓存雪崩的方法比较成熟,例如:统一过期加互斥锁高速缓存永不过期(1)统一过期设置不同的过期时间,以使缓存失效的时间点尽可能均匀。

通常,您可以将一个随机值添加到有效期或统一计划有效期。

缓存密钥过期时间是平均分配的(2)添加互斥锁与缓存崩溃的解决方案相同。

同时,只允许一个线程建立缓存,而其他线程则被阻塞并排队。

互斥访问(3)高速缓存永不过期与高速缓存崩溃解决方案相同的想法是,高速缓存在物理上永不过期,并使用异步线程更新高速缓存。

异步更新缓存。

审查摘要与同事一起审查在线事件之后,每个人都对缓存雪崩有了更深入的了解。

为了避免再次发生缓存雪崩事故,我们一起讨论了几种解决方案:(1)平均到期(2)添加互斥锁(3)缓存永不过期。

希望技术人员能够尊重每一行代码! -END-我特别推荐一种高质量的内容共享架构+算法。

如果您没有关注,则可以长按以关注它:长按以订阅更多令人兴奋的内容▼如果您已获取,请单击以查看,衷心感谢您的免责声明:本文内容由21ic在获得后授权,版权归原作者所有,该平台仅提供信息存储服务。

本文仅代表作者的个人观点,并不代表该平台的立场。

如有任何疑问,请与我们联系,谢谢!