在互联网高并发场景下，数据库读写压力往往是性能瓶颈的第一道关卡。无论是电商秒杀、社交动态流，还是实时排行榜，海量请求瞬间涌入时，直接查询数据库会导致响应延迟飙升甚至系统雪崩。缓存技术作为系统设计中“降本增效”的核心手段，早已成为开发者应对高并发的必备武器。本期“系统设计 014”专栏，我们将深入实战，拆解缓存如何优雅地解决数据库读写痛点，并规避常见陷阱。

缓存为何能提升性能？

缓存的基本原理是将频繁访问的热数据存储在高速存储介质（如内存）中，减少对磁盘数据库的直接查询。内存读取速度可达纳秒级，而磁盘I/O通常在毫秒级，两者相差数个数量级。以Redis为代表的内存缓存系统，配合MySQL等关系型数据库，能实现读写分离与加速——读请求优先命中缓存，写请求则先更新数据库，再同步或异步刷新缓存。这看似简单的策略，在实际落地时却暗藏玄机。

缓存实战策略：读多写少的典型场景

对于“读多写少”的业务（如新闻资讯、商品详情），最常见的模式是Cache-Aside。流程如下：读取时先查缓存，若命中则直接返回；若未命中则查数据库，并回写缓存。写入时优先更新数据库，再删除缓存，等待下次读取时重新加载。为何是删除而非更新？因为删除操作更简单，能避免并发下缓存与数据库数据不一致的复杂问题。

然而，高并发下“缓存未命中”瞬间会放大数据库压力，即缓存击穿。例如一个热点Key过期时，大量请求同时穿透到数据库。解决方案有两种：一是互斥锁，让第一个请求回写缓存，后续等待；二是逻辑过期，缓存永不过期，但内部存储过期时间，异步刷新。实战中，结合本地锁与分布式锁（如Redisson）可有效防护。

三大灾难：穿透、雪崩与一致性

缓存并非万能，若不做好防御，反而会引发更大问题。

缓存穿透：查询一个数据库中不存在的数据，缓存和数据库均无值，每次请求都直击数据库。攻击者可能利用此弱点进行恶意请求。应对方案：布隆过滤器快速排除不存在的数据，或缓存空值（设置较短TTL）。布隆过滤器能以极小的内存空间判断Key是否存在，误判率可控，是拦截穿透的利器。

缓存雪崩：大量缓存Key在同一时间过期，或缓存服务宕机，导致海量请求涌向数据库。解决思路：设置随机过期时间（基础TTL + 随机偏移），防止集体失效；使用多级缓存（本地缓存+分布式缓存），雪崩时本地缓存仍能抗住部分流量；通过限流降级保护数据库，例如Sentinel或Hystrix组件。

数据一致性：缓存与数据库之间的数据同步是永恒难题。强一致性要求高，但会牺牲性能；最终一致性更常见。策略包括：先更新数据库，再异步删除缓存（延迟双删）；使用Canal监听MySQL的binlog，推送给缓存更新。实战中，大部分业务接受秒级延迟，但在金融、库存类场景需谨慎。

实战案例：秒杀系统的缓存设计

以秒杀活动为例，商品库存是典型的写热点。传统做法：库存存于数据库，每次扣减使用行锁或乐观锁，TPS受限。优化方向：用Redis的原子操作（如DECR）扣减库存，异步将最终结果落库。注意要解决库存超卖：先利用Lua脚本保证原子性，再通过消息队列异步持久化。同时，秒杀页面采用页面静态化+CDN缓存，商品详情缓存到Redis，避免每次加载渲染。

总结：缓存的优雅在于“取舍”

缓存并非银弹。它的优雅来自于对业务场景的深度理解：读多写少用Cache-Aside，热点数据用预缓存，防穿透防雪崩要组合布隆过滤器与过期随机化。面对一致性，接受最终一致性，通过补偿机制修复。系统设计的本质是在性能、一致性与复杂度之间找到平衡点。掌握缓存的深度实战，才能让数据库在高并发洪流中岿然不动，让系统架构真正“优雅”起来。