后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载在典型的高并发架构中缓存是降低数据库压力、提升读性能的第一道防线相关背景可参考 10 Essential Components of a Production Web Application 中后端服务通过分布式缓存取数的架构描述。但缓存引入得越多故障形态也越复杂。本文以仓库文档 How Can Cache Systems Go Wrong? 为主线系统拆解缓存系统中最常见的四类故障——Thunder Herd惊群、Cache Penetration穿透、Cache Breakdown热点 Key 失效、Cache Crash宕机并给出对应的工程防御方案。读完本文你将能够准确区分四类故障的触发条件并能在面试或实际架构中为每一类故障选择正确的缓解策略。缓存故障的本质请求绕过缓存直击数据库缓存的价值在于命中故障的代价在于穿透。无论哪一类缓存故障最终表现出来的现象几乎一致本应被缓存挡下的请求成规模地落到了数据库头上数据库连接被打满、响应延迟飙升、甚至引发级联宕机。仓库中的 Things to Consider When Using Cache 一文把缓存设计的考量点归纳为适用场景、读写策略、淘汰算法、关键指标命中率、延迟、吞吐、失效速率、内存/CPU/网络占用以及冷启动惊群、TTL 等其他问题而 How Can Cache Systems Go Wrong? 正是把这些问题中的故障面单独拎出来总结了四类典型故障及其解法。下面逐一展开。1. Thunder Herd Problem缓存惊群问题成因Thunder Herd惊群发生在一大批缓存 Key 同时过期时。当大量 Key 的过期时间被设置为同一个值例如统一设置 TTL 3600 秒它们会在同一时刻集体失效恰在此时涌入的查询请求全部无法命中缓存于是直接打到数据库。数据库瞬时承受数倍于常态的读流量很容易被打爆。需要说明的是惊群问题在缓存冷启动阶段同样存在——系统刚启动、缓存尚未预热时所有请求也会同时落到数据库。仓库文档 Things to Consider When Using Cache 就明确把 Thunder herd on cold start 列为使用缓存时需要留意的其他问题之一。两种缓解方案文档给出了两条并行的缓解思路错开过期时间不要为 Key 设置相同的过期时间而是在基准 TTL 上叠加一个随机数。这样 Key 的过期在时间轴上被打散同一时刻集体过期的概率大大降低。分级保护数据库只允许核心业务数据在缓存未命中时访问数据库对于非核心数据在缓存恢复之前不允许其访问数据库。即通过业务分级把可能打穿缓存的流量限制在最小范围内。工程上的典型落地做法如下示意代码import random BASE_TTL 3600 JITTER_RANGE 300 def set_with_jitter(cache, key, value): # 在基准 TTL 上叠加随机抖动打散集体过期 ttl BASE_TTL random.randint(0, JITTER_RANGE) cache.set(key, value, ttl) def get_data(key, core: bool): data cache.get(key) if data is not None: return data if not core: # 非核心数据缓存未命中时不访问数据库返回兜底值 return DEFAULT_STUB # 核心数据允许回源数据库并回填缓存 data db.query(key) set_with_jitter(cache, key, data) return data除了随机 TTL生产系统中还常用分布式锁 回源重建只允许一个请求重建缓存其余请求等待或返回旧值来进一步抑制惊群。这些都是围绕减少同一时刻对数据库的并发访问这一目标展开的。2. Cache Penetration缓存穿透问题成因缓存穿透是指请求的 Key 在缓存中不存在、在数据库中也同样不存在。应用无法从数据库取到数据来回填缓存于是每次该 Key 的查询都会穿透缓存直达数据库。正常情况下不存在的数据只应出现少量几次但一旦这类 Key 被高频请求尤其是恶意构造的大量不存在 Key缓存就形同虚设缓存与数据库同时承受巨大压力。仓库中的姊妹文档 Cache Miss Attack 将这一场景进一步升级为安全视角的缓存未命中攻击攻击者可以批量发起携带不存在 Key 的请求每个请求最终都会命中数据库使数据库轻易被过载——这正是穿透问题的恶意利用形态。两种解决方案缓存空值对不存在的 Key也向缓存写入一个空值null并设置较短的 TTL。这样后续同样的请求会直接命中缓存中的空值而不再打数据库。配合短 TTL可以避免空值长期占据缓存空间。布隆过滤器前置拦截在缓存之前引入布隆过滤器Bloom Filter快速判断 Key 是否可能存在。若 Key 不存在于布隆过滤器则直接返回连缓存和数据库都不需要访问若 Key 存在再走缓存 → 数据库的正常链路。class CacheAsideWithBloom: def get(self, key): # 布隆过滤器快速判断 key 是否“可能存在” if not self.bloom.might_contain(key): return None # 一定不存在直接返回不碰缓存和数据库 val self.cache.get(key) if val is None: val self.db.query(key) if val is None: # 缓存空值设置短 TTL避免穿透反复打库 self.cache.set(key, EMPTY, short_ttl60) else: self.cache.set(key, val) return val布隆过滤器的本质是以可能存在小概率误判换绝对不存在的确定性判定因此只适合做排除不存在的快速预筛与缓存空值方案可以组合使用。3. Cache Breakdown热点 Key 失效缓存击穿问题成因Cache Breakdown热点 Key 失效常被译为缓存击穿与惊群问题相似但触发条件不同它不是一大批 Key 同时过期而是某一个热点 Key 过期。由于这个 Key 是超高访问频次的明星数据它一失效大量请求会同时涌入数据库。文档明确指出热点 Key 往往占据了约 80% 的查询量因此其失效带来的冲击远比普通 Key 严重。热点 Key 的场景在支付等业务中尤其常见——仓库文档 Handling Hotspot Accounts 就描述了电商大促时商家账户成为热点账户、并发更新导致行锁成为瓶颈的情况。虽然那篇文章讨论的是写热点与行锁但热点数据如何处理的思考路径是相通的热点数据必须被特殊对待不能与普通数据使用同一套失效策略。解决方案文档给出的方案非常直接对热点 Key 不设置过期时间。既然热点数据占据绝大多数查询量让它永驻缓存从根源上消除热点失效导致击穿的可能。但不过期也引入了新问题数据如何更新工程上通常采用两种配套手段逻辑过期 异步刷新物理上不设 TTL但在 value 中写入一个逻辑过期时间戳读到时发现逻辑过期先返回旧值同时触发异步任务回源数据库更新缓存。主动预热与保护性重建在后台任务中周期性刷新热点 Key若仍出现失效瞬间则通过互斥锁mutex保证只有一个请求回源数据库其余请求短暂等待后读取新缓存值。4. Cache Crash缓存宕机问题成因Cache Crash 是指缓存服务整体宕机进程崩溃、节点不可达或集群不可用。此时所有原本应由缓存承接的读请求全部落到数据库数据库会在极短时间内被压垮进而引发更大范围的故障蔓延。缓存宕机往往不是孤立事件数据库被打满后依赖数据库的业务也会连锁失败。仓库文档 Resiliency Patterns 描述了这种小故障引发雪球效应的典型过程并列举了 Timeout、Retry、Circuit Breaker、Rate limiting、Bulkhead、Back pressure 等八种云设计模式来降低故障损害——其中 Circuit Breaker熔断正是本文档针对缓存宕机给出的第一招。两种解决方案熔断器Circuit Breaker为缓存访问设置熔断。当检测到缓存不可用时应用服务既不能访问缓存也不能访问数据库——即主动降级宁可短暂拒绝或返回降级数据也不让请求洪峰压垮数据库。熔断器通常配合超时Timeout、快速失败Fail Fast与退避重试一起使用避免在缓存恢复过程中反复试探导致抖动。缓存集群化为缓存搭建集群如 Redis 主从 哨兵 / Cluster 模式提升缓存自身的可用性。单点缓存变为多节点后单节点故障可以被自动切换或流量重路由吸收从根源上降低缓存整体不可用的概率。class CircuitBreakerCache: def get(self, key): if self.circuit.is_open(): # 熔断打开快速失败不访问缓存与数据库 return self.fallback(key) try: return self.cache.get(key) except CacheUnavailable: self.circuit.trip() # 缓存不可用 → 触发熔断 return self.fallback(key)需要强调的是熔断与集群并非互斥而是互补集群解决缓存自身可用性熔断解决缓存确实不可用时如何保护下游。两者配合才能构成完整的兜底体系。四类故障速查对照故障触发条件核心危害文档给出的缓解方案Thunder Herd惊群大量 Key 同时过期数据库瞬时高并发读基准 TTL 加随机数错开过期按业务核心程度分级放行数据库访问Cache Penetration穿透Key 在缓存和数据库都不存在缓存失效、数据库被高频无效查询打满缓存空值短 TTL布隆过滤器前置拦截Cache Breakdown击穿单个热点 Key 过期热点请求集中冲击数据库热点 Key 不设过期时间配合逻辑过期/异步刷新Cache Crash宕机缓存服务整体不可用全部读流量直落数据库级联故障熔断器缓存、数据库均不可访问缓存集群化提升可用性小结缓存故障治理的通用思路综合四类故障可以看到缓存的防御策略始终围绕两条主线降低同一时刻的穿透量随机 TTL 打散惊群、空值缓存与布隆过滤器拦截穿透、热点 Key 不过期消除击穿本质上都是在降低瞬时打到数据库的请求规模。为最坏情况留后路熔断与集群化解决的是缓存确实不可用时的兜底防止故障从缓存层蔓延到数据库层乃至全系统。值得补充的是缓存的健壮性还依赖日常的指标观测仓库文档 Things to Consider When Using Cache 建议重点跟踪缓存命中率Cache Hit Ratio、失效速率Invalidation Rate、内存与网络占用等指标——命中率异常下降往往是上述某类故障的前兆信号。此外选择与业务访问模式匹配的淘汰策略LRU、LFU、TTL 等详见 Cache Eviction Policies与合适的读写策略Cache Aside、Read/Write Through 等详见 Top 5 Caching Strategies也能在源头上减少缓存失效带来的冲击。如果你正在准备系统设计面试建议将本文的四类故障与 Cache Miss Attack、Cache Systems Every Developer Should Know 中的多层缓存架构、以及 Resiliency Patterns 中的熔断/限流模式一起串读形成缓存层 → 数据库层 → 全局容错的完整防御视图。这类故障识别 方案选型的论述正是系统设计面试中高频考察的能力点。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐缓存系统全景指南System Design 101 项目中的 8 层缓存体系详解缓存系统全景指南System Design 101 项目中的 8 层缓存体系详解 缓存Cache是现代分布式系统性能优化的基石从浏览器端到数据库后端数后端文档教程GitHub_Trending/sys/system-design缓存策略Top 5缓存模式及其应用场景GitHub_Trending/sys/system design缓存策略Top 5缓存模式及其应用场景 引言为什么缓存是现代系统设计的核心 还在为数据库文档教程知识库System Design 101特征存储系统设计指南——从概念到实践的完整解析System Design 101特征存储系统设计指南——从概念到实践的完整解析 在机器学习和数据系统设计中特征存储Feature Store是连接数据后端文档教程上一篇【免费下载】 开源项目推荐夸克网盘自动化神器 —— Quark-Auto-Save下一篇BySMB项目下载与安装教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考