这次我们来看软件架构与设计系列的第 3 部分分布式缓存。在分布式系统里缓存不能只被当成“性能优化手段”它更是决定系统能否扛住峰值流量、能否控制数据库成本、能否保证端到端延迟稳定的基础设施层。很多团队排查线上问题时把锅甩给“数据库慢查询”但深入看往往是缓存层设计不正确key 设计随意、过期策略选错、更新时出现脏数据、大 key 和热 key 没有治理、命中率从未监控。这篇文章会把分布式缓存拆成几个可以直接落地验证的模块先讲它的核心能力与适用边界再讲读写流程和典型机制然后是缓存更新策略与一致性方案接着给出一套可复制的部署接入示例、性能观察方法、常见问题排查清单和最佳实践。如果你正在做后端开发、做架构设计或者准备面试中缓存相关的题目这篇文章可以直接收藏。1. 分布式缓存核心能力速览先给一张速览表把分布式缓存最关键的几个能力项列出来方便快速判断它在整个系统里承担什么角色。能力项说明缓存类型本地进程内缓存、集中式远程缓存、多级缓存组合典型组件Redis、Memcached、Caffeine、Guava Cache、Hazelcast主要功能数据读取加速、热点数据隔离、跨服务状态共享、分布式锁、计数与限流数据淘汰策略LRU、LFU、TTL 过期、随机淘汰、按内存上限逐出高可用方案主从复制、哨兵模式、Cluster 集群分片一致性模型通常采用最终一致性部分场景可做到近似强一致适合场景读多写少、热点数据、接口幂等与去重、并发控制不适合场景强事务依赖、超大 value、复杂聚合查询、敏感数据无脱敏缓存核心监控指标命中率、内存使用率、QPS、平均延迟、大 key 与热 key 分布从表中可以清晰看到分布式缓存解决的核心问题是让大量读请求不再直接打到数据库而是从更快的内存存储中拿到数据。但缓存不是银弹它的引入会带来一致性问题、运维成本和故障面扩大必须在设计阶段就进行约束。2. 适用场景与使用边界2.1 适合的场景分布式缓存最适合处理“读多写少、数据变化频率不高、对一致性的要求不是绝对严苛”的数据。日常工作中这些场景最常见接口热点数据缓存比如商品详情、用户信息、配置信息、字典数据。这类数据读请求量大但更新频率相对低非常适合放在缓存里。跨服务共享状态多个微服务需要共享某些状态比如登录 token、设备状态、任务进度。此时缓存集群充当轻量级共享存储。分布式锁与并发控制基于 Redis 的 SETNX 或 Redisson 实现分布式锁避免多个实例同时操作同一资源。计数与限流接口限流、验证码发送次数、点赞计数等场景利用 Redis 的 INCR 和 EXPIRE 在极短时间内完成原子计数。热点数据隔离当数据库某一行记录被频繁访问时通过缓存隔离对数据库的直接压力避免单行热点压垮数据库。2.2 不适合的场景有几类场景不建议使用分布式缓存强事务和强一致场景缓存无法替代数据库事务。如果业务要求多数据源强一致应该依赖数据库本身的 ACID 特性而不是在缓存层做文章。低频冷数据一个月才访问一次的数据放进缓存没有任何收益只会白白占用内存。超大 value单条数据超过几百 KB 甚至几 MB直接放入 Redis 会带来严重问题内存浪费、网络传输慢、阻塞其他命令执行。超大 value 应该拆分成多个小 key或者存入对象存储。复杂聚合查询多表 Join 后的聚合结果并不适合原样缓存因为任何一个关联表变化都会导致缓存失效一致性难以维护。2.3 使用边界与合规要求缓存里经常会放用户信息、手机号、身份证号、订单信息等敏感数据。在设计与实现上需要明确边界不允许把未脱敏的用户敏感信息直接写入缓存必须做好脱敏或加密处理。缓存数据的访问权限要与业务系统权限体系对齐不能因为“缓存方便”就绕过权限校验。数据从缓存读取后在页面或接口返回前仍需进行脱敏处理。涉及用户肖像、声音、版权素材等业务数据必须确认授权范围和缓存时长不能无限期缓存。3. 架构选型与前置准备3.1 缓存分层生产环境中常见的是“本地缓存 集中式缓存”的多级缓存架构。一级缓存进程内缓存Caffeine、Guava Cache。放在应用进程内读取速度最快零网络开销但是每个实例各持一份存在数据不一致和内存占用问题。二级缓存集中式缓存Redis、Memcached。多实例共享同一份缓存数据容量大支持过期策略和持久化是分布式系统中的核心缓存层。多级缓存的问题在于一致性同步。一级缓存一般只缓存变动极少的配置数据并设置很短的过期时间比如 1 到 5 分钟避免缓存长时间不一致。3.2 技术选型维度选型时不建议只看“哪个缓存工具流行”而是按以下几项去评估评估维度说明数据结构支持Redis 支持 String、Hash、List、Set、ZSetMemcached 主要支持 KV持久化能力Redis RDB/AOFMemcached 不持久化高可用方案Redis 哨兵与 ClusterMemcached 依赖客户端分片运维生态Redis 有 RedisInsight、Prometheus exporter社区资料丰富部署成本单机 Redis 和集群 Redis 的运维复杂度差异较大从当前生态看Redis 已经是事实标准本文后续示例也以 Redis 为主。如果需要进程内、零延迟的本地缓存则配合 Caffeine 使用。3.3 前置准备清单开始部署前需要准备好以下内容操作系统Linux、macOS、Windows 均可生产环境以 Linux 为主。运行环境Redis 6.x 或 7.xDocker 方式启动更简单。客户端依赖Spring Boot 项目引入 spring-boot-starter-data-redis或直接使用 Jedis、Lettuce。端口规划默认 6379多实例部署时需要规划不同端口。安全组与防火墙生产环境限制 6379 端口仅允许业务服务器访问避免暴露到公网。4. 核心读写流程与关键机制4.1 标准缓存读写流程PostgreSQL 或 MySQL 等数据库无法承受全部读流量时缓存层介入的经典流程如下写请求先写数据库再删除缓存或更新缓存。读请求先查缓存命中则直接返回未命中则查询数据库将结果写入缓存并设置过期时间最后返回给调用方。这个流程也被称为 Cache Aside 模式是分布式缓存中最常见、最容易理解的读写流程。它最大的特点是业务代码显式控制缓存读写灵活性最高排查问题最直观。需要注意先删缓存再写库还是先写库再删缓存业界建议优先“先更新数据库再删除缓存”。原因在于“更新数据库 删除缓存”操作在多数场景下更安全因为删除一个不存在的 key 不会产生脏数据。而“先删缓存再更新数据库”在更新数据库失败或者期间有读请求进来时容易出现缓存和数据库不一致。4.2 缓存穿透缓存穿透指的是查询一个数据库和缓存中都不存在的数据。此时缓存没有命中请求直接打到数据库如果攻击者构造大量不存在的 key数据库压力会瞬间爆掉。解决方案缓存空值将不存在的 key 也以 null 值缓存设置 60 到 120 秒的短过期时间。下一次同样的 key 直接命中缓存。布隆过滤器在缓存前加一层布隆过滤器拦截绝大多数不存在的 key。参数校验在接口入口对明显非法参数直接拒绝。4.3 缓存击穿缓存击穿是指某个热点 key 过期的瞬间大量并发请求同时访问数据库。和穿透不同击穿针对的是“存在但并发极高的单一 key”。解决方案互斥锁当缓存未命中时只允许一个线程去加载数据库其他线程等待结果。逻辑过期不给 key 设置物理过期时间而是把过期时间放在 value 中。读到逻辑过期数据时异步去后台更新缓存。热点数据永不过期由后台任务定时刷新热点 key适合更新频率可控的数据。4.4 缓存雪崩缓存雪崩是指大量 key 在同一时段集中过期或者缓存服务整体不可用导致所有请求落到数据库数据库瞬间被打垮。与击穿的区别在于雪崩是“大规模 key 同时失效”。解决方案过期时间加随机值每个 key 的过期时间在基础 TTL 上增加随机偏移避免同一时刻集体失效。缓存高可用Redis 主从 哨兵或 Cluster防止缓存节点单点故障。多级缓存兜底本地缓存作为最后一道防线即使 Redis 挂掉仍有进程内缓存抗住一部分流量。限流降级当缓存不可用时通过熔断和降级机制保护数据库。5. 缓存更新策略与一致性方案5.1 四种缓存读写策略对比策略读写方式优点缺点Cache Aside业务代码显式读写缓存先写库后删缓存实现简单灵活性高一致性依赖业务代码可能出现短暂不一致Read Through读请求由缓存中间件透明处理缓存未命中时由缓存加载数据库业务代码更简洁对缓存中间件功能要求高配置复杂Write Through写数据时同步写缓存和数据库读请求一致性强写路径延迟变高Write Behind写数据时先写缓存异步批量写回数据库写性能最好服务宕机时可能丢失数据从实践角度绝大多数团队在业务代码中选择 Cache Aside在数据库中间件层面可能选择 Read Through / Write Through。Write Behind 通常使用在允许数据少量丢失的统计类场景。5.2 缓存与数据库的一致性方案缓存和数据库是两种不同特性的存储要做到真正意义上的强一致非常困难且成本很高。实际工程里的核心思路是“最终一致性 尽量缩短不一致时间窗口”。常见方案延迟双删先删除缓存再更新数据库然后延迟几百毫秒再次删除缓存。目的是解决并发场景下读请求写入旧值的问题。异步消息更新数据库更新成功后发 MQ 消息消费者接收后删除对应缓存。适合解耦复杂业务链路。Binlog 订阅通过 Canal 订阅 MySQL binlog拿到数据变更后异步更新缓存。对业务代码无侵入是很多中大型系统采用的方式。版本号机制缓存 value 中携带数据版本号读缓存时校验版本号低于当前版本时主动回源并刷新缓存。这几种方案各有适用边界不能直接说哪种最好。核心原则是先用 TTL 作为兜底再结合业务并发程度选择是否加延迟双删、MQ 或 binlog。5.3 什么时候需要放弃缓存一致性当业务要求极高的强一致性比如账户余额、订单支付状态这类数据不建议走“缓存为主”的读取路径。这类数据应当每次从数据库读取或使用单机内存加锁的方式实现强一致。缓存更适合“展示型数据”和“过程状态数据”。6. 部署接入与调用示例下面给出一套可直接操作的 Redis 部署与 Spring Boot 接入示例。环境为 Docker Spring Boot假设你本机已经具备 Docker 环境。6.1 使用 Docker 启动 Redis# 启动 Redis 6.x 单机实例端口映射到宿主机 6379 docker run -d --name redis-cache \ -p 6379:6379 \ -e REDIS_PASSWORDredis123456 \ redis:6.2-alpine \ redis-server --requirepass redis123456启动后验证连接# 进入容器执行命令 docker exec -it redis-cache redis-cli -a redis123456 ping # 预期输出PONG生产环境一般不会直接用明文密码参数而是使用 Docker Compose 或 K8s Secret 管理配置。下面是一个 Docker Compose 示例version: 3.8 services: redis: image: redis:6.2-alpine container_name: redis-cache restart: always ports: - 6379:6379 command: redis-server --appendonly yes --requirepass redis123456 volumes: - redis-data:/data volumes: redis-data:6.2 Spring Boot 接入 Redis在pom.xml中引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency在application.yml中配置连接信息spring: data: redis: host: 127.0.0.1 port: 6379 password: redis123456 timeout: 3000ms lettuce: pool: max-active: 16 max-idle: 8 min-idle: 26.3 编写一个简单的缓存读写示例创建一个示例 Service模拟商品信息的缓存读写import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Service; import org.springframework.util.StringUtils; import java.time.Duration; Service public class ProductCacheService { private static final String PRODUCT_CACHE_KEY_PREFIX product:detail:; private final RedisTemplateString, String redisTemplate; public ProductCacheService(RedisTemplateString, String redisTemplate) { this.redisTemplate redisTemplate; } /** * 先查缓存未命中则回源数据库 */ public String getProductDetail(String productId) { String cacheKey PRODUCT_CACHE_KEY_PREFIX productId; String cacheValue redisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cacheValue)) { return cacheValue; } // 模拟回源数据库查询结果 String dbValue loadFromDatabase(productId); if (dbValue null) { // 缓存空值 60 秒防止缓存穿透 redisTemplate.opsForValue().set(cacheKey, , Duration.ofSeconds(60)); return null; } // 设置 30 分钟过期时间 redisTemplate.opsForValue().set(cacheKey, dbValue, Duration.ofMinutes(30)); return dbValue; } /** * 更新商品信息先写库再删除缓存 */ public void updateProduct(String productId, String productInfo) { // 1. 更新数据库 updateDatabase(productId, productInfo); // 2. 删除缓存 String cacheKey PRODUCT_CACHE_KEY_PREFIX productId; redisTemplate.delete(cacheKey); } private String loadFromDatabase(String productId) { // 实际项目中这里调用 DAO 或 Mapper return 商品详情- productId; } private void updateDatabase(String productId, String productInfo) { // 实际项目中这里调用 DAO 或 Mapper } }这个示例把标准 Cache Aside 流程变成了可运行的代码结构读请求先查缓存未命中回源后写缓存写请求先更新数据库再删除缓存。它覆盖了缓存穿透空值缓存和 TTL 兜底是比较完整的入门模板。6.4 API 服务化调用如果缓存中间件本身需要开放 API 给第三方系统不建议直接暴露 Redis 协议而是封装一层 HTTP 接口服务。下面给出一个通用的 API 封装思路实际路径和参数需要按项目情况调整# fastapi 示例仅演示缓存服务化封装思路 from fastapi import FastAPI import redis app FastAPI() cache redis.Redis(host127.0.0.1, port6379, passwordredis123456, decode_responsesTrue) app.get(/cache/{key}) def get_cache(key: str): value cache.get(key) if value is None: return {code: 404, data: None} return {code: 0, data: value} app.post(/cache/{key}) def set_cache(key: str, value: str, ttl: int 300): cache.set(key, value, exttl) return {code: 0, data: True} app.delete(/cache/{key}) def delete_cache(key: str): cache.delete(key) return {code: 0, data: True}# curl 调用示例 curl -X POST http://127.0.0.1:8000/cache/user:1001 \ -H Content-Type: application/json \ -d {value: {\name\:\test\}, ttl: 300} curl http://127.0.0.1:8000/cache/user:1001将缓存封装为 API 服务后可以统一接入权限校验、审计日志、key 命名规范和频控策略多个团队不需要直接接触 Redis 连接细节。7. 性能观察与容量规划7.1 关键监控指标分布式缓存上线后至少要观察以下指标指标说明正常参考范围命中率缓存命中次数占总请求比例业务缓存建议 90% 以上内存使用率Redis 已用内存与 maxmemory 的比例建议不超过 80%平均延迟GET/SET 命令的平均耗时通常在 1ms 以内慢查询数执行时间超过阈值的命令次数长时间为 0 或极低大 key 数量value 很大的 key 数量应持续治理越少越好热 key 访问量单个 key 的 QPS 占比需要观察是否过度集中观察方法使用 Redis 自带的 INFO 命令查看内存和命中率使用 RedisInsight 或 Grafana Prometheus 展示趋势曲线对 Spring Boot 项目可以接入 Actuator 暴露 Redis 连接池指标。# 登录 Redis 后执行 redis-cli -a redis123456 INFO stats INFO memory INFO commandstats重点关注keyspace_hits与keyspace_misses两个计数器命中率通过两者计算命中率 keyspace_hits / (keyspace_hits keyspace_misses)7.2 容量估算方法容量规划时主要考虑三个方面单 key 平均大小以实际业务数据序列化后的字节数估算。key 总数按业务量估算比如用户数、订单数、商品数的数倍。峰值内存单 key 大小乘以 key 总数再乘以预留的淘汰余量。# 估算公式 预估内存 单 key 平均大小 × 预估 key 总数 × 1.5预留淘汰与扩展空间例如单 key 平均 1KB预计 1000 万个 key则预估内存为 1KB × 1000 万 × 1.5 15GB。如果采用 Redis Cluster 3 主 3 从那么每个主节点大约存储 5GB 数据实例规格可以按 8GB 内存规划。7.3 如何降低缓存资源占用使用更紧凑的序列化方式例如 Protobuf、MsgPack 替代 JSON。拆分公司字段和业务字段避免一个 key 塞入十几 KB 的冗余数据。合理设置 TTL既不能太长导致数据长期不更新也不能太短导致重复回源。对大 value 做拆分把列表类型拆成多个小 key或者存储摘要信息需要完整数据时再查对象存储。开启 Redis 内存淘汰策略例如 allkeys-lru避免缓存写满以后 OOM。# redis.conf 片段 maxmemory 8gb maxmemory-policy allkeys-lru注意开启内存淘汰策略后Redis 会在内存达到上限时按策略删除部分 key业务上要能容忍缓存数据被提前淘汰。8. 常见问题与排查方法问题现象可能原因排查方式解决方案缓存命中率持续偏低过期时间设置太短、key 设计不合理、缓存未覆盖真正的读热点查看 keyspace_hits/misses 统计及 slowlog调整 TTL分析热点 key增加多级缓存数据库在缓存过期后突然压力变大大量 key 同一时间过期查看 key 过期时间和数量分布设置随机 TTL 偏移错峰过期某个 key 访问量巨大Redis 节点 CPU 飙升热 key 问题请求全部集中在一个节点使用 redis-cli --hotkeys 或接入热 key 识别工具key 热点分散增加本地缓存二级缓存缓存热 key单个 key 的 value 有几百 KB读取耗时高大 key 问题使用 redis-cli --bigkeys 扫描拆分大 key改为小 key 聚合查询或压缩存储缓存与数据库数据不一致更新顺序错误、并发删除缓存与读取覆盖对比缓存 value 与数据库记录分析日志调整为先写库再删缓存必要时延迟双删或 MQ 更新应用频繁报连接超时连接池耗尽或 Redis 连接数超过上限查看连接池监控和 Redis clients 信息调整连接池大小排查慢命令占用连接内存增长异常快出现淘汰告警缓存 key 过多或单 key 过大INFO memory 查看已用内存和碎片率清理无效 key优化序列化方式配置 maxmemory-policyRedis 重启后缓存全部丢失未开启 RDB 或 AOF或持久化配置错误检查 redis.conf 中 save 参数、appendonly 参数开启 AOF 并配置合适刷盘策略缓存中出现未脱敏敏感数据业务代码直接缓存用户敏感字段排查缓存 key 和 value 内容对敏感字段脱敏或加密后再写入缓存这些问题是缓存系统上线后最常遇到的。排查时不要只盯缓存本身要从“写入路径、读取路径、过期机制、监控数据”四个角度联合分析。9. 最佳实践与使用建议9.1 key 命名规范建议统一使用“业务域:对象:ID:属性”的格式例如order:detail:1001:base。这样做的好处是从 key 名就能判断数据归属、方便按前缀批量管理、对 Redis Cluster 哈希槽分布也更友好。禁止使用无意义的随机串作为 key否则问题定位和清理都很困难。9.2 value 序列化选择简单 KV 结构使用 String序列化用 JSON 或 MsgPack。对象结构优先使用 Hash单个字段可以单独更新。列表结构使用 List 或 ZSet注意控制单个 key 的元素数量。二进制大对象压缩后存储或者转到对象存储不在 Redis 中做主力存储。9.3 TTL 设计原则所有缓存 key 都应该设置过期时间。TTL 不是配置得越长越好而是按照业务容忍的数据最大不一致时间来确定。比如商品基础配置可以设 30 分钟用户会话状态设 2 小时验证码设 5 分钟。另外生产环境建议在基础 TTL 上增加 5% 到 10% 的随机偏移防止大范围 key 同时过期。9.4 多级缓存与降级开关推荐在 Redis 之前增加 Caffeine 本地缓存形成“本地缓存 - Redis - 数据库”三级结构。本地缓存只配置极少数的热点数据并设置 1 到 5 分钟短过期。同时在缓存调用链路上加入降级开关当 Redis 不可用时可以跳过 Redis 直接读数据库或者只读本地缓存并返回部分数据。不要把所有缓存都设计成强依赖要让系统在缓存故障时有降级路径。9.5 安全与合规建议缓存中不能存储未脱敏的敏感信息涉及用户手机号、身份证、地址、人脸特征、声音样本等数据必须脱敏或加密。缓存访问要限制调用来源生产环境不要将 Redis 端口暴露到公网。封装缓存 API 服务时需要做鉴权、限流、审计。涉及版权素材和用户肖像使用时必须确认授权范围和缓存时长严禁将未授权内容长期保存在缓存系统中。9.6 发布前验证清单是否所有缓存 key 都设置了 TTL是否处理了缓存击穿、穿透、雪崩三个风险更新数据库后是否正确删除缓存是否监控缓存命中率、内存、QPS、慢查询是否具备缓存不可用时的降级方案是否存在大 key 和热 key 风险敏感数据是否脱敏或加密10. 总结与下一步分布式缓存不是一个单独组件就能解决问题的技术它必须和业务读写路径、过期策略、一致性方案、监控体系组合起来才能发挥价值。这套内容里最先要验证的永远是三个基础点缓存命中率是否达到预期、缓存与数据库更新顺序是否正确、缓存故障时系统是否有降级路径。最容易踩的坑也集中在这三点上更新顺序错了导致脏数据、热点 key 没有识别导致节点压力失衡、缓存挂掉后数据库被突发流量打垮。后续可以继续扩展的方向包括Redis Cluster 分片与数据迁移、缓存与 MQ 结合的一致性方案、基于 Redisson 的分布式锁增强实现、以及多级缓存场景下的 Caffeine 配置调优。先把本文中的读写流程、更新策略、监控指标和排查清单在测试环境完整跑一遍再逐步应用到线上高流量业务中会比你直接照搬别人的配置要稳妥得多。建议收藏备用等真正做缓存治理的时候再看一遍。