阅读量:0
热点文件（尤其是大文件）在查询或下载过程中，涉及大量的元信息访问。如果元信息较大且访问 QPS 较大时，就会导致实例网卡打满、CPU爆表，造成缓存失效（缓存击穿）；流量直接打到 DB 上，造成大量读请求超时、连接打满、机器挂掉（服务雪崩）。直接对服务可用性造成打击，一般都是重大事故。
造成这种结果的本质原因是缓存设计和使用不合理。直接原因是缓存对象指向的文件是热门资源。一般文件系统很少关心文件或者文件对象指向的内容，所以在这类热点发生时往往很被动。需要告警阈值提醒，人工及时介入处理和止损（封禁、扩容）。
理想的方式是对文件粒度的读访问限流，但是很少这么做，就像普通用户 Windows 系统装防火墙一样...代价大价值很难凸显。比较常用的方法是对缓存下手，业务侵入小，普适性高。
前提是需要梳理业务逻辑，对目标对象的缓存本身进行分析，哪些情况QPS 达到多少就会有隐患。然后再分析一下可用的方案，一般有三种处理方式：
本地缓存
在合适的业务节点实例上，申请一定大小的空间用于本地缓存。将需要被缓存的一定大小以上的元数据作为缓存对象。需要自行实现淘汰算法，支持过期时间，支持内容校验。由于流量的负载均衡和随机性，需要埋点查看缓存命中率，估计效果。
这种方式可以解决集中热点问题，但是无法根治。命中率随着流量随机性的降低而升高，这取决于流量分发层策略和设计。
缓存数据压缩
一般压缩率可观，但是遇到超大文件仍然无法根本解决问题。
大 key 拆解
这种需要对缓存数据中的作用和业务需求有全面的分析，分类讨论。抽象出基本信息，多 key信息存储。直接影响是原来获取一次，现在需要获取多次，极端情况下，有长尾请求的 bad case，可以根据具体情况优化逻辑，全局考虑下一般可接受。由于大 key 拆分，需要先改校验规则，再上线新逻辑。
综上，正对业务使用的大 key缓存需求，本质要求设计者和编程者懂业务，对缓存目标有一定的认知，了解缓存的利弊，使用时根据情况取舍粒度，全面思考和逻辑闭环。
