redis 缓存击穿事件记录

记录：今天发生一起严重线上事故  数据库崩溃导致服务不可用。排查时发现10：16左右数据库达到6700qps。

检查后发现：运营配置了活动10：17的秒杀活动。导致流量倍增。本身这里是用了缓存的。3分钟的缓存。在缓存失效后

第一个请求的结果没有写入到redis之前。这段时间的6000+请求量全部涌入到数据库.导致数据库瘫痪。

 

解决方案（个人，可能会有遗漏）：

1：本次活动时前n名免单，用户一直刷新商品页面，实际上对库存要求不时很高。主要原因就是平凡刷新的问题。

可以写定时任务，在缓存失效前一段时间，查询一次缓存 更新到redis中。 比如 3分钟的缓存，可以在更新缓存时，触发一个定时任务：这个定时任务在2分30秒后查询数据库，手动更新缓存。这样缓存可以永远不失效，永远命中缓存。

 

2：如果是真正的有限库存的秒杀类型，可以让秒杀高峰期，缓存永不失效。订单通过队列来处理，处理前插叙缓存库存是否为0.每个订单扣减库存都放在缓存里做，绝不去查询数据库。当缓存为0时 拒绝订单，并且修改数据库库存。 这样做对数据库完全没什么压力。压力主要在接口上。就可以通过nginx转发，异步队列和多加服务节点来解决。