系统设计 014缓存深度实战如何用 Cache 优雅优化数据库读写Bilibili 同步视频一、Cache 的能力边界能优化读但写不动1.1 读场景的优化原理1.2 写场景的挑战二、两大缓存架构选对架构少走 90% 弯路2.1 Cache Aside 架构业界通用的万金油2.2 Cache Through 架构一体化的专属方案2.3 架构选择指南三、写多读少场景小厂的破局之道3.1 水平扩展策略3.2 数据库分片实战3.3 写优化补充方案四、缓存实战避坑指南与最佳实践4.1 常见缓存问题与解决方案缓存穿透缓存雪崩缓存击穿4.2 缓存监控与调优五、总结Cache 优化的核心心法5.1 进阶思考5.2 工具推荐Bilibili 同步视频系统设计 014缓存深度实战如何用 Cache 优雅优化数据库读写在高并发系统设计里数据库性能永远是绕不开的核心命题。而 Cache 作为性能优化的神兵利器常常被我们用来应对海量请求、缓解数据库压力。但很多开发者都会陷入一个误区Cache 真的能优化一切吗今天我们就从读写场景、架构选型、落地实践三个维度把 Cache 优化这件事讲透 ✨。一、Cache 的能力边界能优化读但写不动先抛出一个直击本质的结论Cache 可以极致优化数据库读操作却对写操作束手无策。为什么会有这样的差异我们拆解底层逻辑读多场景下请求直接从 Cache 读取跳过数据库查询链路响应速度呈指数级提升系统瓶颈瞬间被打破 ⚡写多场景下每次数据修改都必须同步更新数据库Cache 不仅帮不上忙还需要主动删除缓存数据直接导致Cache Miss读取效率大幅下降。更关键的是多线程、多进程场景下若强行同步更新 Cache 与数据库极易出现数据不一致线程 A 刚更新完数据库还未同步 Cache线程 B 就写入新数据最终 Cache 会存入旧数据形成脏读直接影响系统稳定性。本质原因很简单写操作的瓶颈在数据库本身而非读取链路Cache 无法绕过数据库完成写入自然没有优化空间。1.1 读场景的优化原理当读请求到达时系统会先检查缓存中是否存在所需数据缓存命中Cache Hit数据在缓存中直接返回响应时间通常在毫秒级缓存未命中Cache Miss数据不在缓存中需要查询数据库然后将结果写入缓存// 伪代码示例读缓存逻辑publicObjectgetData(Stringkey){// 1. 先查缓存Objectdatacache.get(key);if(data!null){returndata;// 缓存命中}// 2. 缓存未命中查数据库datadatabase.query(key);// 3. 写入缓存设置过期时间if(data!null){cache.set(key,data,300);// 缓存5分钟}returndata;}1.2 写场景的挑战写操作必须保证数据一致性常见的缓存更新策略有先更新数据库再删除缓存Cache-Aside先删除缓存再更新数据库双写策略同时更新缓存和数据库无论哪种策略写操作都无法避免数据库的IO瓶颈。二、两大缓存架构选对架构少走 90% 弯路既然 Cache 有明确边界想要用好它必须先吃透两大主流缓存架构根据业务场景精准选型 。2.1 Cache Aside 架构业界通用的万金油这是目前互联网行业最常用的架构核心逻辑是分离管控、自由组合由 Web Server 统一调度分别与 Cache、数据库通信Cache 和数据库互不直接交互各自独立运作典型代表Memcache、Redis MySQL适配绝大多数业务场景。优势明显兼容性极强Cache 和数据库可自由搭配无论是传统关系型数据库还是新型 NoSQL都能无缝对接小厂、大厂都能轻松落地。适用场景电商商品详情页用户个人信息新闻资讯内容社交动态信息// Cache Aside 模式实现示例publicclassCacheAsideService{privateCachecache;privateDatabasedatabase;publicObjectread(Stringkey){// 1. 先读缓存Objectvaluecache.get(key);if(value!null){returnvalue;}// 2. 读数据库valuedatabase.select(key);// 3. 写入缓存if(value!null){cache.set(key,value,300);}returnvalue;}publicvoidwrite(Stringkey,Objectvalue){// 1. 先更新数据库database.update(key,value);// 2. 删除缓存而不是更新cache.delete(key);}}2.2 Cache Through 架构一体化的专属方案与 Cache Aside 完全不同它将 Cache 和数据库封装为一个整体系统自动完成数据从 Cache 到数据库的同步典型代表Redis持久化模式、一些云数据库的缓存层。但它有明显短板仅支持 Key-Value 存储面对范围查询、复杂关联查询等场景直接力不从心。这种架构通常只有大厂有能力自研定制小厂很难承担研发与维护成本。适用场景简单的配置信息存储会话Session管理排行榜数据计数器功能2.3 架构选择指南对比维度Cache AsideCache Through复杂度低易于理解和实现高需要深度定制灵活性高可自由组合存储方案低绑定特定存储一致性需要手动维护自动保证理论上适用规模中小型到大型项目大型到超大型项目维护成本低高综上日常开发优先选 Cache Aside简单通用、容错率高是性价比最高的选择 ✅。三、写多读少场景小厂的破局之道最棘手的问题来了业务写多读少Cache 失效该如何优化答案很直白却最实用堆机器 数据库分片Sharding。3.1 水平扩展策略增加数据库节点横向扩容硬件资源平摊海量写请求读写分离主库负责写多个从库负责读通过数据库 Sharding 技术拆分读写流量让每台数据库只负责一部分数据的读写从架构层面解决写瓶颈。这不是笨办法而是小厂成本最低、风险最小、落地最快的务实选择后续结合 Sharding 精细化设计性能还能再上一个台阶 。3.2 数据库分片实战// 简单的分片策略示例publicclassShardingStrategy{// 基于用户ID的分片publicStringgetShardKey(StringuserId){inthashuserId.hashCode();intshardCount4;// 假设有4个分片intshardIndexMath.abs(hash%shardCount);returnshard_shardIndex;}// 获取对应的数据库连接publicConnectiongetShardConnection(StringuserId){StringshardKeygetShardKey(userId);returnconnectionPool.get(shardKey);}}3.3 写优化补充方案除了分片还可以考虑批量写入将多次写操作合并为一次批量操作异步写入非实时性要求的数据可以异步处理消息队列缓冲用消息队列承接写请求平滑写入压力冷热数据分离将历史数据归档减少主表压力四、缓存实战避坑指南与最佳实践4.1 常见缓存问题与解决方案缓存穿透问题查询不存在的数据每次都打到数据库解决方案布隆过滤器Bloom Filter预判缓存空值设置较短过期时间缓存雪崩问题大量缓存同时失效请求直接打到数据库解决方案设置不同的过期时间加随机值热点数据永不过期熔断降级机制缓存击穿问题热点key过期大量并发请求打到数据库解决方案互斥锁Mutex Lock逻辑过期不设置物理过期时间// 解决缓存击穿的互斥锁实现publicObjectgetDataWithLock(Stringkey){Objectdatacache.get(key);if(data!null){returndata;}// 获取分布式锁StringlockKeylock:key;if(tryLock(lockKey)){try{// 双重检查datacache.get(key);if(data!null){returndata;}// 查询数据库datadatabase.query(key);if(data!null){cache.set(key,data,300);}else{// 缓存空值防止穿透cache.set(key,EMPTY_VALUE,60);}returndata;}finally{releaseLock(lockKey);}}else{// 等待其他线程加载Thread.sleep(50);returngetDataWithLock(key);}}4.2 缓存监控与调优监控指标缓存命中率Hit Rate缓存使用率Memory Usage响应时间Response TimeQPS/TPS调优策略根据业务特点设置合理的过期时间使用LRU/LFU等淘汰策略监控慢查询优化缓存key设计定期清理无用缓存五、总结Cache 优化的核心心法最后用三句话总结今天的核心知识点方便大家快速记忆读多场景用 Cache写多场景靠扩容认清边界不盲目使用首选 Cache Aside 架构通用灵活适配绝大多数业务小厂不纠结自研堆机器 Sharding轻松搞定写压力。5.1 进阶思考缓存优化不是一劳永逸的需要根据业务发展持续调整初期简单Cache Aside快速上线成长期引入读写分离监控缓存命中率成熟期精细化分片多级缓存架构大规模期定制化缓存方案结合CDN等5.2 工具推荐本地缓存Caffeine、Guava Cache分布式缓存Redis、Memcached监控工具Prometheus Grafana压测工具JMeter、wrk系统优化没有银弹只有贴合业务、吃透原理才能让 Cache 真正发挥价值撑起高并发系统的性能天花板 。扩展阅读Redis 官方文档缓存设计模式数据库分片实战下期预告我们将深入探讨「分布式锁的七种实现方式」敬请期待。
系统设计 014：缓存深度实战：如何用 Cache 优雅优化数据库读写？
系统设计 014缓存深度实战如何用 Cache 优雅优化数据库读写Bilibili 同步视频一、Cache 的能力边界能优化读但写不动1.1 读场景的优化原理1.2 写场景的挑战二、两大缓存架构选对架构少走 90% 弯路2.1 Cache Aside 架构业界通用的万金油2.2 Cache Through 架构一体化的专属方案2.3 架构选择指南三、写多读少场景小厂的破局之道3.1 水平扩展策略3.2 数据库分片实战3.3 写优化补充方案四、缓存实战避坑指南与最佳实践4.1 常见缓存问题与解决方案缓存穿透缓存雪崩缓存击穿4.2 缓存监控与调优五、总结Cache 优化的核心心法5.1 进阶思考5.2 工具推荐Bilibili 同步视频系统设计 014缓存深度实战如何用 Cache 优雅优化数据库读写在高并发系统设计里数据库性能永远是绕不开的核心命题。而 Cache 作为性能优化的神兵利器常常被我们用来应对海量请求、缓解数据库压力。但很多开发者都会陷入一个误区Cache 真的能优化一切吗今天我们就从读写场景、架构选型、落地实践三个维度把 Cache 优化这件事讲透 ✨。一、Cache 的能力边界能优化读但写不动先抛出一个直击本质的结论Cache 可以极致优化数据库读操作却对写操作束手无策。为什么会有这样的差异我们拆解底层逻辑读多场景下请求直接从 Cache 读取跳过数据库查询链路响应速度呈指数级提升系统瓶颈瞬间被打破 ⚡写多场景下每次数据修改都必须同步更新数据库Cache 不仅帮不上忙还需要主动删除缓存数据直接导致Cache Miss读取效率大幅下降。更关键的是多线程、多进程场景下若强行同步更新 Cache 与数据库极易出现数据不一致线程 A 刚更新完数据库还未同步 Cache线程 B 就写入新数据最终 Cache 会存入旧数据形成脏读直接影响系统稳定性。本质原因很简单写操作的瓶颈在数据库本身而非读取链路Cache 无法绕过数据库完成写入自然没有优化空间。1.1 读场景的优化原理当读请求到达时系统会先检查缓存中是否存在所需数据缓存命中Cache Hit数据在缓存中直接返回响应时间通常在毫秒级缓存未命中Cache Miss数据不在缓存中需要查询数据库然后将结果写入缓存// 伪代码示例读缓存逻辑publicObjectgetData(Stringkey){// 1. 先查缓存Objectdatacache.get(key);if(data!null){returndata;// 缓存命中}// 2. 缓存未命中查数据库datadatabase.query(key);// 3. 写入缓存设置过期时间if(data!null){cache.set(key,data,300);// 缓存5分钟}returndata;}1.2 写场景的挑战写操作必须保证数据一致性常见的缓存更新策略有先更新数据库再删除缓存Cache-Aside先删除缓存再更新数据库双写策略同时更新缓存和数据库无论哪种策略写操作都无法避免数据库的IO瓶颈。二、两大缓存架构选对架构少走 90% 弯路既然 Cache 有明确边界想要用好它必须先吃透两大主流缓存架构根据业务场景精准选型 。2.1 Cache Aside 架构业界通用的万金油这是目前互联网行业最常用的架构核心逻辑是分离管控、自由组合由 Web Server 统一调度分别与 Cache、数据库通信Cache 和数据库互不直接交互各自独立运作典型代表Memcache、Redis MySQL适配绝大多数业务场景。优势明显兼容性极强Cache 和数据库可自由搭配无论是传统关系型数据库还是新型 NoSQL都能无缝对接小厂、大厂都能轻松落地。适用场景电商商品详情页用户个人信息新闻资讯内容社交动态信息// Cache Aside 模式实现示例publicclassCacheAsideService{privateCachecache;privateDatabasedatabase;publicObjectread(Stringkey){// 1. 先读缓存Objectvaluecache.get(key);if(value!null){returnvalue;}// 2. 读数据库valuedatabase.select(key);// 3. 写入缓存if(value!null){cache.set(key,value,300);}returnvalue;}publicvoidwrite(Stringkey,Objectvalue){// 1. 先更新数据库database.update(key,value);// 2. 删除缓存而不是更新cache.delete(key);}}2.2 Cache Through 架构一体化的专属方案与 Cache Aside 完全不同它将 Cache 和数据库封装为一个整体系统自动完成数据从 Cache 到数据库的同步典型代表Redis持久化模式、一些云数据库的缓存层。但它有明显短板仅支持 Key-Value 存储面对范围查询、复杂关联查询等场景直接力不从心。这种架构通常只有大厂有能力自研定制小厂很难承担研发与维护成本。适用场景简单的配置信息存储会话Session管理排行榜数据计数器功能2.3 架构选择指南对比维度Cache AsideCache Through复杂度低易于理解和实现高需要深度定制灵活性高可自由组合存储方案低绑定特定存储一致性需要手动维护自动保证理论上适用规模中小型到大型项目大型到超大型项目维护成本低高综上日常开发优先选 Cache Aside简单通用、容错率高是性价比最高的选择 ✅。三、写多读少场景小厂的破局之道最棘手的问题来了业务写多读少Cache 失效该如何优化答案很直白却最实用堆机器 数据库分片Sharding。3.1 水平扩展策略增加数据库节点横向扩容硬件资源平摊海量写请求读写分离主库负责写多个从库负责读通过数据库 Sharding 技术拆分读写流量让每台数据库只负责一部分数据的读写从架构层面解决写瓶颈。这不是笨办法而是小厂成本最低、风险最小、落地最快的务实选择后续结合 Sharding 精细化设计性能还能再上一个台阶 。3.2 数据库分片实战// 简单的分片策略示例publicclassShardingStrategy{// 基于用户ID的分片publicStringgetShardKey(StringuserId){inthashuserId.hashCode();intshardCount4;// 假设有4个分片intshardIndexMath.abs(hash%shardCount);returnshard_shardIndex;}// 获取对应的数据库连接publicConnectiongetShardConnection(StringuserId){StringshardKeygetShardKey(userId);returnconnectionPool.get(shardKey);}}3.3 写优化补充方案除了分片还可以考虑批量写入将多次写操作合并为一次批量操作异步写入非实时性要求的数据可以异步处理消息队列缓冲用消息队列承接写请求平滑写入压力冷热数据分离将历史数据归档减少主表压力四、缓存实战避坑指南与最佳实践4.1 常见缓存问题与解决方案缓存穿透问题查询不存在的数据每次都打到数据库解决方案布隆过滤器Bloom Filter预判缓存空值设置较短过期时间缓存雪崩问题大量缓存同时失效请求直接打到数据库解决方案设置不同的过期时间加随机值热点数据永不过期熔断降级机制缓存击穿问题热点key过期大量并发请求打到数据库解决方案互斥锁Mutex Lock逻辑过期不设置物理过期时间// 解决缓存击穿的互斥锁实现publicObjectgetDataWithLock(Stringkey){Objectdatacache.get(key);if(data!null){returndata;}// 获取分布式锁StringlockKeylock:key;if(tryLock(lockKey)){try{// 双重检查datacache.get(key);if(data!null){returndata;}// 查询数据库datadatabase.query(key);if(data!null){cache.set(key,data,300);}else{// 缓存空值防止穿透cache.set(key,EMPTY_VALUE,60);}returndata;}finally{releaseLock(lockKey);}}else{// 等待其他线程加载Thread.sleep(50);returngetDataWithLock(key);}}4.2 缓存监控与调优监控指标缓存命中率Hit Rate缓存使用率Memory Usage响应时间Response TimeQPS/TPS调优策略根据业务特点设置合理的过期时间使用LRU/LFU等淘汰策略监控慢查询优化缓存key设计定期清理无用缓存五、总结Cache 优化的核心心法最后用三句话总结今天的核心知识点方便大家快速记忆读多场景用 Cache写多场景靠扩容认清边界不盲目使用首选 Cache Aside 架构通用灵活适配绝大多数业务小厂不纠结自研堆机器 Sharding轻松搞定写压力。5.1 进阶思考缓存优化不是一劳永逸的需要根据业务发展持续调整初期简单Cache Aside快速上线成长期引入读写分离监控缓存命中率成熟期精细化分片多级缓存架构大规模期定制化缓存方案结合CDN等5.2 工具推荐本地缓存Caffeine、Guava Cache分布式缓存Redis、Memcached监控工具Prometheus Grafana压测工具JMeter、wrk系统优化没有银弹只有贴合业务、吃透原理才能让 Cache 真正发挥价值撑起高并发系统的性能天花板 。扩展阅读Redis 官方文档缓存设计模式数据库分片实战下期预告我们将深入探讨「分布式锁的七种实现方式」敬请期待。
