缓存击穿这个词语在很多程序开发者来讲是再熟悉不过了。当下互联网大流量的环境下，缓存几乎可以说是在当前软件开发应用中必不可少的一点了。
先简单介绍下业务场景，在渠道引流的过程中，下放引流利益点声明，引流之后针对完成任务的有效用户进行之前承诺利益点的发放，承诺有效期自然周有效。 以此引流拉新业务为目标，程序上分为四大模块，分别是 承诺声明利益点的展示模块、千人千面实时分析模块、分析结果业务管理模块、利益点发放模块。
此次事件发生在业务管理模块， 按业务声明诉求，当用户实时访问合作方系统时，会实时展示出渠道引流利益点，引导用户进入我们系统，转换成我司的有效用户。利益点承诺本周有效。服务系统内部流程大体如图：
此次事件发生在日常期间，因为结果自然周有效缓存key设计为PRE_userId_yyyy_第N周，当自然周末凌晨，缓存key大批量失效，流程直接打到数据库，数据库查询和写入量激增，几十万的写入直接把库压死，直接导致数据库连接瞬间打满数据库不可用。
解决方案大部分在上图已经标记了，包括业务的降级和限流等相关措施，另外还有一点很重要的是缓存大批量到期问题没有在上图说明，关于缓存到期问题，我们采用的是缓存双周记录法，也就是写缓存的时候同步写入当月缓存之后，在提交MQ发送结果的task任务中自降级实现另一份缓存的写入 ，希入key为当前周+1，缓存有效期按当周剩余时间+用户哈希取模%分段阈值*步长（分段阈值和步长均可动态运行时覆盖调整，视具体业务周期而定）
下面说下之前跟朋友聊的时候有的一些问题如果你也有类似想法可以考虑下下面的建议
缓存击穿这种问题我也遇到过，但是我怎么没有你这么多的问题呢，我那啥事也没有啊。对于有此类想法的朋友，我建议你把你现在的业务系统结构整理一下，然后按流量放大10倍甚至是1000倍之后再考虑下这个问题。我们这个系统 日常流量大概在QPS大概在2-5W之间，大规模促销引流的时候，峰值大概在140W左右。
另外可能有人没有看明白我们这个系统的主要作用在哪，其实很简单，它属于千人千面输出的一个最上层，对接千人千面进行分析，然后保存分析结果，直接业务有效期结束之前要尽可能的保证查询结果的幂等性。按上面的业务就是承诺的和最后下发的利益点要相同
个人感受：大流量就像是放大镜一样，在放大到我们发现问题太多的时候 ，基本上也就是你的系统达到瓶颈的时候了。不同的流量阶段会有不同的设计方案，如果我们想了解我们系统的阈值的话。大流量或许是一个很好的手段。
公众号同步推送：大流量放大镜下看缓存击穿事件