开学季集中测评可能形成明显的访问高峰。容量规划应以实际学校数量、参与人数、开始时间和请求模型为基础，并用压测验证，而不是只根据报名人数推断并发量。
题库和学校配置等读多写少的数据可以考虑缓存，答卷写入则需单独评估数据库容量、限流和持久化可靠性。是否需要Redis，应由实际负载与架构决定。
下面以集中测评为假设场景，说明缓存雪崩和穿透的防御思路。
缓存雪崩（Cache Avalanche）：过期时间的致命共振
假设技术团队在 9 月 1 日凌晨，通过一段脚本将 500 套心理量表和各大学校的配置信息，全部预热到了 Redis 中，并极其统一地设置了“24 小时后过期”。
灾难发生在了 9 月 2 日的凌晨。
那 24 小时的倒计时结束了。成千上万个极度重要的缓存 key 在同一秒钟极其整齐地集体失效（被 Redis 自动清理）。
如果在这一瞬间，正好有几千个熬夜做测试的请求打过来，它们去 Redis 里一摸，发现什么都没有！于是这几千个请求如同决堤的洪水，瞬间全部穿过 Redis，狠狠地砸在毫无防备的 MySQL 身上。MySQL 的 CPU 瞬间飙到 100%，连接池被打爆，全站宕机。
可在基础 TTL 上增加随机偏移，例如24小时加0至3600秒，以分散集中到期的概率。它并不保证流量均匀或完全避免回源高峰，仍需结合预热、回源限流与监控。
缓存穿透（Cache Penetration）：黑客的致命狙击
相比于雪崩的内伤，缓存穿透往往是遭到恶意狙击的结果。
反复查询不存在的ID可能产生缓存穿透。应先做参数和访问权限检查，再考虑短时空值缓存或布隆过滤器；按已建索引的ID查询，不一定发生全表扫描。
布隆过滤器：快速排除未加入集合的ID
在完整同步且正常维护的前提下，布隆过滤器返回“不存在”表示该ID未加入集合；返回“可能存在”仍需继续查询。过滤器不负责证明访问者有权查看该报告，授权检查必须单独完成。
标准布隆过滤器的误判是假阳性：不存在的ID可能被判断为“可能存在”，而不是把已加入的真实ID误判为不存在。若真实记录被挡，应排查同步遗漏、初始化或实现问题，不应提供绕过权限的隐藏接口。
总结
TTL随机扰动、布隆过滤器与回源控制解决的是不同问题。上线前应验证数据同步、权限校验和故障降级，并持续观察缓存命中率与数据库负载。