本文共 863 字，大约阅读时间需要 2 分钟。
近期公司推出了一个商品抢购活动，由于后台操作失误，导致活动效果不佳，引发了用户和代理商的投诉。老大让我与同事一起复盘这次线上事故。
抢购活动原本计划在0点准时开始，22点运营人员通过后台将商品上线。23点后台小哥已经将商品导入缓存中，提前预热。
抢购开始时流量非常大，预计Redis将承担大部分用户查询请求，避免所有请求都落在数据库上。
根据预期，大部分请求应该命中缓存。然而，后台小哥在预热缓存时，将所有商品的缓存时间设置为2小时过期。结果，在同一时间点，所有商品的缓存同时失效，所有请求都落到了数据库上，导致数据库无法承受压力，崩溃，用户请求全部超时报错。
凌晨1:02，SRE收到系统告警，登录运维管理系统发现数据库节点CPU和内存飙升超过阈值，迅速联系后台开发人员定位排查。
缓存设置过期时间是2小时，凌晨1点前缓存可以命中大部分请求，数据库服务处于正常状态。
后台小哥通过日志定位排查问题后，采取了以下措施：
这次事故的根本原因是缓存雪崩，查询数据量巨大，请求直接落到数据库上，导致数据库压力过大宕机。
业界解决缓存雪崩的方法有以下几种：
设置不同的过期时间，失效时间点尽量均匀。通常为有效期增加随机值或统一规划有效期。
跟缓存击穿解决思路一致，同一时间只让一个线程构建缓存，其他线程阻塞排队。
跟缓存击穿解决思路一致，缓存在物理上永远不过期，用一个异步的线程更新缓存。
通过与同事复盘这次线上事故，大家对缓存雪崩有了更深刻的理解。为了避免类似问题，我们讨论了多个解决方案：
希望技术人能够敬畏每一行代码！
转载地址：http://dlbr.baihongyu.com/