| ||||||||||||||||||||||||||||||||||||
在电商系统中，本地缓存（如 Caffeine、Guava Cache、Ehcache 等）因 “无网络开销、访问速度极快（微秒级）” 的特性，适用于特定业务场景。其核心优势是降低分布式缓存压力、提升单机响应速度，但受限于 “仅本地节点可见” 的特性，需避开 “跨服务数据共享”“强一致性要求” 的场景。以下是本地缓存的典型适用场景： 一、高频访问且数据静态化的场景 1. 商品基础信息（非价格 / 库存） 场景描述：商品的固定属性，如商品名称、品牌、类目、规格参数（颜色、尺寸）、详情页静态图文等，这类数据更新频率极低（可能几天或几周更新一次），且访问量极大（每个商品详情页请求都会读取）。 适配理由： 数据几乎不变，无需频繁更新本地缓存，避免一致性问题； 高频访问可通过本地缓存拦截 90% 以上的请求，减少分布式缓存（如 Redis）的压力，尤其在大促期间能显著降低网络 IO 开销。 实践方式：启动时从数据库或分布式缓存加载全量数据到本地缓存，更新时通过消息通知各节点主动刷新。 2. 系统配置与字典数据 场景描述：电商系统的全局配置，如促销活动规则（满减门槛、优惠券使用限制）、支付渠道列表（微信、支付宝）、地区编码（省 / 市 / 区映射）、订单状态字典（待付款、已发货等）等，这类数据全系统共享且变更频率低。 适配理由： 配置数据被各服务（订单、支付、商品）高频读取（如每笔订单需校验活动规则），本地缓存可避免重复查询数据库或分布式缓存； 数据量通常较小（几千至几万条），占用内存少，不易引发 OOM。 实践方式：采用 “定时拉取 + 变更推送” 机制，例如每小时从配置中心（如 Nacos）拉取最新配置，同时配置变更时通过事件通知各节点即时更新本地缓存。
二、热点数据的临时缓存 1. 热点商品 / 活动页缓存 场景描述：大促期间的 “爆款商品”（如某款手机 1 小时内被访问 100 万次）、首页活动 Banner（如 618 主会场入口图），这类数据在短时间内访问量激增，且允许 “短暂不一致”（如价格微调后延迟 1 分钟生效）。 适配理由： 热点数据的访问集中在少数商品，本地缓存可直接在单机层面拦截请求，避免分布式缓存成为瓶颈（如 Redis 单节点 QPS 上限约 10 万，而本地缓存可支撑百万级 QPS）； 即使个别节点缓存数据稍旧，也可通过 “短过期时间”（如 1 分钟）快速淘汰，配合分布式缓存兜底，保证最终一致性。 实践方式：结合 “热点探测”（如通过访问日志识别前 100 名热点商品 ID），主动将其加载到本地缓存，设置较短的过期时间（如 30 秒），过期后从分布式缓存更新。 2. 防重复提交令牌 场景描述：用户提交订单、支付、评论等操作时，需生成唯一令牌（Token）防止重复提交（如用户快速点击 “提交订单” 按钮），令牌需在短时间内（如 5 分钟）有效，且仅需当前服务节点验证。 适配理由： 令牌是临时数据（过期即失效），无需跨服务共享，本地缓存可直接存储 “令牌 - 用户 ID” 映射，验证时直接本地查询，避免分布式缓存的网络延迟； 令牌生成和验证频率高（尤其大促期间），本地缓存的高性能可支撑高并发场景。 实践方式：用户请求生成令牌时，将令牌存入本地缓存并设置 5 分钟过期，提交时校验令牌是否存在，存在则删除令牌（原子操作），防止重复提交。
三、计算密集型结果缓存 1. 商品搜索过滤条件缓存 场景描述：用户搜索商品时，前端需要展示筛选条件（如 “价格区间”“品牌列表”“销量排序选项”），这些条件通常由后端根据商品库动态计算生成（如从 10 万商品中统计出 “价格区间 [0-500 元]”“[500-1000 元]” 等），计算过程耗时（约 100-500ms），但结果在短时间内稳定。 适配理由： 筛选条件的计算依赖全量商品数据，每次请求重新计算会占用大量 CPU，本地缓存可存储计算结果，后续请求直接复用，降低服务负载； 筛选条件允许 5-10 分钟的延迟更新（如新增商品后，筛选条件无需立即刷新），适合本地缓存的 “懒更新” 策略。 实践方式：首次请求时计算筛选条件，将结果存入本地缓存并设置 10 分钟过期，过期后自动重新计算并更新。 2. 个性化推荐结果缓存 场景描述：基于用户行为（如浏览历史、收藏记录）生成的个性化推荐列表（如 “猜你喜欢”），这类结果由算法实时计算（耗时约 200-1000ms），但用户短时间内（如 10 分钟）的推荐结果可复用。 适配理由： 推荐算法计算密集，本地缓存可缓存 “用户 ID - 推荐商品列表” 映射，避免重复计算，提升页面加载速度； 个性化结果仅对当前用户有效，无需跨节点共享，本地存储即可满足需求。 实践方式：用户首次访问推荐页时触发算法计算，结果存入本地缓存（设置 10 分钟过期），后续访问直接返回缓存结果，过期后重新计算。
四、不适用场景的排除 本地缓存虽高效，但需明确避开以下场景，避免业务异常： 跨服务共享数据：如购物车（需同步 PC 端和 APP 端数据）、用户会话（需跨服务验证登录状态），这类场景必须用分布式缓存； 强一致性要求：如库存数量（需实时同步减库存操作）、订单状态（支付后需立即更新为 “已付款”），本地缓存可能因节点数据不一致导致超卖或状态错误； 大数据量存储：如全量订单记录、用户行为日志，本地缓存受限于单机内存，易引发 OOM。 总之，本地缓存的核心价值是 “用空间换时间”，在电商系统中优先适用于高频读、低更新、非跨服务共享、允许短暂不一致的场景，如静态商品信息、系统配置、热点数据临时存储等。使用时需配合合理的过期策略（如 TTL）和更新机制（如事件通知），同时与分布式缓存形成互补（多级缓存），才能在高并发场景下兼顾性能与可靠性。 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
|
