在电商系统中，缓存架构的选择和使用直接影响系统性能、稳定性和数据一致性，稍有不慎可能引发缓存雪崩、数据错乱等严重问题。以下从架构选择、使用规范、风险防控三个维度，梳理核心注意事项：
一、缓存架构选择的注意事项
选择本地缓存、分布式缓存或混合架构时，需结合业务特性、数据属性和系统目标，避免盲目选型：
1. 明确数据特性与缓存适配性
不同数据的 “访问频率、更新频率、一致性要求” 决定了缓存类型的适配性，需提前梳理：
高频读、低频写、一致性要求低：如商品分类、品牌介绍等静态数据，优先用本地缓存（Caffeine/Guava），减少分布式缓存压力。
高频读、高频写、一致性要求中：如商品详情、用户购物车，适合分布式缓存（Redis 集群），通过 “更新时主动失效缓存” 保证最终一致。
高频读、高频写、强一致性：如秒杀库存、实时价格，需分布式缓存 + 数据库双写（如 Redis+MySQL，结合 Lua 脚本原子操作），避免超卖。
超大 Value 数据：如商品详情页的富文本描述（10KB 以上），不适合本地缓存（占用 JVM 内存），建议用分布式缓存并拆分存储（基础信息 + 详情内容分开缓存）。
2. 分布式缓存集群架构选型
集群模式：中小规模用 Redis 主从 + 哨兵（成本低），大规模用 Redis Cluster（分片扩展，支持 10 万 + QPS），避免单节点瓶颈。
数据分片策略：热点商品（如爆款）单独分片，避免 “一 key 独大” 拖垮整个集群；普通商品用哈希分片（hash (key) % 分片数），均匀分配负载。
持久化与备份：开启 RDB+AOF 混合持久化（RDB 做全量备份，AOF 记录增量操作），防止集群宕机后数据丢失（如秒杀库存数据需 100% 恢复）。
3. 混合架构的协同原则
本地缓存与分布式缓存配合时，需明确 “谁为主、谁为辅”：
本地缓存作为分布式缓存的前置缓存：优先查本地，未命中再查分布式缓存，减少网络 IO（如首页高频访问的商品列表）。
分布式缓存作为本地缓存的同步源：本地缓存更新时，通过消息队列通知其他节点同步（如用户登录状态，本地缓存 + Redis，登录成功后广播失效其他节点的本地缓存）。
二、缓存使用规范与最佳实践
1. 缓存 Key 设计
命名规则：统一格式业务模块:数据类型:唯一标识[:属性]，如product:info:12345（商品 12345 的基础信息）、order:status:67890（订单 67890 的状态），便于排查问题。
避免过长 Key：Key 长度超过 100 字节会增加内存占用和网络传输成本，如用商品 ID 哈希值代替长名称（product:info:${hash(id)}）。
过期时间必设：所有缓存必须设置过期时间（即使是静态数据，如 24 小时），避免内存泄漏；热点数据过期时间错开（如 10 分钟 ±1 分钟），防止缓存雪崩。
2. 缓存更新策略
根据数据一致性要求选择合适的更新方式：
Cache Aside（旁路缓存）：读操作先查缓存，未命中查 DB 并回写缓存；写操作先更 DB，再删缓存（避免 “更新缓存” 导致的脏数据），适合大部分电商场景。
Write Through（写透）：写操作同时更新 DB 和缓存（同步），适合强一致场景（如库存），但性能较低（需两次写操作）。
Write Back（写回）：写操作先更新缓存，异步批量更新 DB（如用户浏览记录），适合非核心数据，需容忍短暂不一致。
反例：更新商品价格时直接 “set 缓存”，可能导致并发场景下的旧值覆盖新值（如 A 更新价格到 100，B 更新到 90，缓存先写 B 的 90，再写 A 的 100，最终缓存是 100，正确；但如果顺序相反，缓存会存旧值 90）。正解：更新 DB 后 “删除缓存”，下次读时从 DB 加载新值回写。
3. 缓存穿透防护
空值缓存：查询不存在的商品（如 ID=-1）时，缓存空值（null）并设置短期过期（如 5 分钟），避免恶意请求穿透到 DB。
布隆过滤器：将所有有效商品 ID 预加载到布隆过滤器（如 Redis 的 Bloom Filter 插件），请求先过过滤器，不存在则直接返回，适合亿级数据场景。
案例：秒杀活动中，黑客伪造 10 万 + 不存在的商品 ID 请求，若未做防护，会直接压垮数据库；通过布隆过滤器拦截后，99% 的无效请求被缓存层拦截。
4. 缓存雪崩与击穿处理
缓存雪崩：大量缓存同时过期，导致请求瞬间压向 DB。
解决：缓存过期时间加随机值（如 30 分钟 ±5 分钟），避免集中过期；分布式缓存集群多机房部署，避免单机房故障。
缓存击穿：热点 Key（如爆款商品）过期瞬间，大量请求穿透到 DB。
解决：热点 Key 永不过期（通过后台定时任务更新）；互斥锁（如 Redis 的 SETNX），只允许一个线程查 DB 并回写缓存，其他线程等待重试。
三、风险防控与监控
1. 数据一致性风险
核心数据强校验：库存、订单等数据，缓存与 DB 定期对账（如每小时全量比对，差异量超过 1% 触发告警），不一致时以 DB 为准修复缓存。
缓存更新重试机制：删除 / 更新缓存失败时（如 Redis 网络超时），通过消息队列重试（最多 3 次），避免 “更新了 DB 但缓存未失效” 导致的长期不一致。
2. 性能与资源风险
本地缓存内存控制：设置最大容量（如 Caffeine 的maximumSize）和过期时间，避免 OOM；定期清理冷数据（如 LRU 淘汰策略）。
分布式缓存负载监控：实时监控 Redis 的 CPU 使用率（>80% 告警）、内存碎片率（>1.5 需重启）、响应延迟（>50ms 需扩容），大促前提前扩容分片。
3. 全链路监控与告警
埋点指标：缓存命中率（目标 > 90%）、平均响应时间（本地 <1ms，Redis<10ms）、穿透率（<1%）、更新成功率（>99.9%）。
告警阈值：命中率突降 10%、穿透率 > 5%、Redis 节点宕机，通过钉钉 / 短信实时通知运维，避免问题扩大。
总之，电商缓存架构的核心是 “在性能、一致性、成本之间找平衡”：静态数据用本地缓存提效，核心数据用分布式缓存保一致，混合架构通过规则动态协同；同时需通过 Key 设计、过期策略、防护机制规避穿透 / 雪崩风险，最终通过监控和对账确保系统稳定。实际落地时，建议从小规模场景验证（如商品详情页），逐步推广到全链路，避免一次性架构改造引入风险。
