| ||||||||||||||||||||||||||||||||||||
电商系统的缓存策略选择需紧密结合其业务场景特性（如读写频率、数据一致性要求、流量波动）和技术架构特点（如微服务拆分、数据存储分布），避免 “一刀切”。以下是针对电商核心场景的缓存策略选择方法，按业务模块分类说明： 一、商品模块：读多写少，优先优先保证响应速度 商品模块（商品详情、分类列表、搜索结果）是电商系统的 “流量入口”，特点是读请求量极大（占比 90%+）、写操作少（仅商品上下架 / 编辑时更新）、数据变更频率低。 核心目标：最大化缓存命中率，减少数据库压力，支撑高并发读。 1. 缓存策略选择 缓存介质：分布式缓存（Redis）为主，本地缓存（Caffeine）为辅（缓存热点商品）。 更新策略：Cache-Aside（先更库，再删缓存） 流程：更新商品信息时，先修改数据库，再删除对应缓存 Key（而非直接更新缓存），下次读请求会自动从数据库加载最新数据并写入缓存。 优势：避免 “更新缓存” 的额外开销，适合写频率低的场景。 过期策略： 普通商品：设置中等过期时间（如 30 分钟）+ 随机偏移量（避免集中失效）。 热点商品（如爆款、首页推荐）：逻辑永不过期（移除物理过期时间），通过后台定时任务主动更新缓存。 特殊处理： 商品搜索结果：缓存分页数据（如search:手机:page1），设置较短过期时间（如 5 分钟），结合搜索引擎（Elasticsearch）的缓存机制。 商品规格 / 库存：库存数据单独缓存（product:1001:stock），与商品基本信息分离，避免库存高频更新导致基本信息缓存频繁失效。
二、订单模块：写多读少，需保证数据一致性 订单模块（订单创建、状态更新、历史查询）的特点是写操作密集（下单、支付、发货等状态变更）、读操作集中在用户查询历史订单、数据强一致性要求（如订单状态必须实时准确）。 核心目标：平衡缓存效率与数据一致性，避免因缓存导致业务异常（如显示已取消但实际已支付）。 1. 缓存策略选择 缓存介质：分布式缓存（Redis），不建议用本地缓存（避免多实例数据不一致）。 更新策略：Write-Through（先更库，再同步更新缓存） 或 异步更新（基于消息队列） 核心订单状态（如 “待支付”“已发货”）：采用 Write-Through，更新数据库后立即更新缓存（如order:12345 → {status: "已支付", ...}），确保读请求能获取最新状态。 非核心数据（如订单物流轨迹）：数据库更新后发送 MQ 消息，异步更新缓存，减少主流程耗时。 过期策略： 近期订单（30 天内）：缓存时间较长（如 7 天），方便用户频繁查询。 历史订单（30 天以上）：不缓存或设置短过期时间（如 1 小时），通过数据库分页查询，减少缓存内存占用。 特殊处理： 订单 ID 生成：用 Redis 生成自增 ID（incr order_id），避免数据库自增 ID 的性能瓶颈。 防重复下单：用 Redis 分布式锁（setnx order:lock:user123 → 1）确保同一用户同一商品不会重复下单。 三、购物车模块：高频读写，需兼顾性能与实时性 购物车模块（添加商品、修改数量、删除商品）的特点是读写频率都极高（用户可能反复操作）、数据与用户强绑定（每个用户的购物车独立）、允许短暂不一致（如商品价格变动，下次打开时刷新即可）。 核心目标：支撑高频读写，减少数据库交互，同时保证用户操作流畅。 1. 缓存策略选择 缓存介质：分布式缓存（Redis），推荐用 Hash 结构存储（如cart:user123 → {商品ID1: 数量, 商品ID2: 数量}）。 更新策略：直接写缓存，异步同步数据库 流程：用户添加 / 修改购物车时，先更新 Redis（如hincrby cart:user123 1001 1），再通过异步线程或 MQ 同步到数据库（避免阻塞用户操作）。 优势：写操作耗时极短（Redis 单命令微秒级），用户体验流畅。 过期策略： 登录用户购物车：长期有效（与用户账号绑定），数据库定期同步备份。 游客购物车：设置过期时间（如 7 天），用户登录后合并到账号购物车。 特殊处理： 商品价格 / 库存校验：用户结算时，从数据库或商品缓存重新校验价格和库存，避免缓存中的旧数据导致下单异常。
四、促销模块：高并发场景，需抗住流量峰值 促销模块（秒杀、优惠券、满减活动）的特点是流量极端集中（如秒杀开始瞬间 QPS 突增 100 倍）、数据时效性强（活动开始 / 结束时间严格）、业务逻辑复杂（库存扣减、优惠叠加）。 核心目标：通过缓存扛住流量峰值，避免系统崩溃，同时保证库存准确性。 1. 缓存策略选择 缓存介质：本地缓存（Caffeine）+ 分布式缓存（Redis Cluster），多级缓存分担压力。 更新策略：缓存预热 + 原子操作 活动前预热：提前将活动商品信息、库存、规则加载到 Redis 和本地缓存（如seckill:1001 → {stock: 1000, price: 99}）。 库存扣减：用 Redis 原子命令（decr seckill:1001:stock）处理，避免超卖，再异步同步到数据库。 过期策略： 活动商品：缓存时间覆盖整个活动周期，活动结束后立即失效。 优惠券：缓存用户可领取的优惠券列表（coupon:user123），设置短过期时间（如 1 分钟），避免缓存与实际领取状态偏差过大。 特殊处理： 限流防护：在 Redis 层通过incr+ 过期时间实现接口限流（如seckill:limit:user123限制单用户每秒 1 次请求）。 热点分离：将超热门商品（如秒杀手机）的缓存单独部署，避免影响其他活动。 五、用户模块：读写均衡，需保护敏感数据 用户模块（登录信息、个人资料、地址管理）的特点是读写频率中等、数据敏感性高（如手机号、地址）、安全性要求高（避免缓存泄露）。 核心目标：缓存非敏感数据提升体验，同时防止敏感信息泄露。 1. 缓存策略选择 缓存介质：分布式缓存（Redis），敏感数据（如密码）不缓存。 更新策略：Cache-Aside 非敏感数据（如用户名、等级）：更新数据库后删除缓存，下次读取时刷新。 登录令牌（Token）：直接写入 Redis（token:xxx → userID），设置与 Token 有效期一致的过期时间，实现自动登出。 过期策略： 用户资料：中等过期时间（如 2 小时），避免频繁更新。 地址列表：较长过期时间（如 7 天），结合用户主动更新触发缓存刷新。 特殊处理： 防缓存穿透：用户 ID 不存在时，缓存空值（如user:9999 → null，过期时间 5 分钟）。 敏感数据脱敏：缓存用户信息时，对手机号、邮箱等脱敏（如138****5678）。
六、通用策略选择原则 按 “读写比” 决策： 读多写少（商品、分类）：优先用 Cache-Aside，最大化缓存命中率。 写多读少（订单状态）：用 Write-Through 或异步更新，保证一致性。 高频读写（购物车）：直接写缓存 + 异步同步，优先保证性能。 按 “一致性要求” 决策： 强一致性（支付状态、库存）：缓存更新需同步或加锁，避免数据偏差。 最终一致性（商品销量、用户积分）：允许短暂不一致，用异步更新（MQ + 定时任务）兜底。 按 “流量特性” 决策： 流量平稳（日常商品浏览）：常规缓存策略即可。 流量波动大（大促、秒杀）：多级缓存 + 预热 + 限流，扛住峰值。 总之，电商系统选择缓存策略的核心是 **“场景化适配”**：先分析业务模块的读写频率、一致性要求、流量特征，再匹配对应的缓存介质（本地 / 分布式）、更新策略（Cache-Aside/Write-Through）、过期规则。同时，需通过监控（命中率、响应时间）和压测验证策略有效性，在大促等关键节点前优化调整，最终实现 “性能提升” 与 “风险可控” 的平衡。 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
|
