事故的背景公司最近安排了一波商品购买活动。
由于后台兄弟的操作错误，活动结果很差，遭到用户和代理商的抱怨。
经理要我带我的同事来回顾在线事故。
是什么原因造成的？抢购活动计划按时从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在获得后授权，版权归原作者所有，该平台仅提供信息存储服务。
本文仅代表作者的个人观点，并不代表该平台的立场。
如有任何疑问，请与我们联系，谢谢！
