缓存模块拆分应围绕访问模式、更新频率、数据依赖和一致性边界展开，按业务域、数据粒度、访问路径等逻辑划分，而非单纯追求细粒度；例如用户、商品、订单分域缓存，详情与库存分离，订单拆为子项，销量单独计数，首页用本地缓存、个人中心用分布式缓存。
构建缓存时，模块拆分不是为了“切得细”，而是为了让每一块缓存更聚焦、更可控、更容易命中。关键不在于拆多少，而在于按什么逻辑拆——核心是围绕访问模式、更新频率、数据依赖和一致性边界来组织模块。
按业务域与读写特征拆分
把缓存模块按业务实体或功能边界划分，比如用户中心、商品中心、订单中心各自独立缓存，避免混用同一套 key 命名或过期策略。不同域的数据变化节奏差异大：用户资料更新少但查询频，适合长 TTL；购物车数据更新频繁但生命周期短，适合短 TTL + 主动失效。混在一起会导致要么缓存太旧，要么频繁刷新拖慢性能。
- 用户模块：缓存 user:1001 → 用户基本信息，TTL 设为 2 小时，配合登录态变更主动失效
- 商品模块：缓存 item:8892:detail 和 item:8892:stock 分开，详情页变动少，库存变动快，分开存储可避免因库存更新导致详情缓存被误淘汰
- 配置类模块：如 feature:flag 或 region:config，用统一短 TTL（如 5 分钟）+ 版本号控制，便于灰度发布时精准刷新
按数据粒度与组合关系拆分
避免“一锅炖”式缓存大对象。例如不要缓存整个订单详情（含用户、地址、商品、优惠券），而应拆成 order:12345:base、order:12345:items、order:12345:coupons 等子键。这样既能提升复用率（多个接口共用 items），又能降低更新成本（仅优惠券变更时只刷新 coupons 子项）。
- 聚合查询场景下，可额外提供组合缓存（如 order:12345:summary），但它的生成必须依赖原子子项，不能绕过子项直连数据库
- 对高频读、低频写的字段（如商品销量），单独拆出 counter:item:8892:sales，用 INCR 原子操作更新，避免序列化整条记录
按访问路径与冷热分离拆分
区分“入口级缓存”和“计算级缓存”。首页推荐、搜索结果这类高并发、强时效性请求，走本地缓存（Caffeine）+ 短 TTL + 预加载；而用户个人中心这种个性化、低并发请求，走分布式缓存（Redis）+ 长 TTL + 懒加载。两者互不干扰，也不会因某类请求突增导致另一类缓存被挤出。
- 本地缓存用于兜底和降级，容量小但响应快（
- 分布式缓存用于共享与协同，容量大但网络耗时存在（0.2–1ms），适合承载 80% 中低频数据
- 冷数据（如半年前订单）不进缓存，直接查库；可通过归档标记或访问日志自动识别并剔除
按一致性要求与更新方式拆分
对强一致场景（如账户余额），缓存模块必须与数据库事务联动，采用 Cache Aside + 延迟双删；对最终一致场景（如评论数、浏览量），可用 Write-Behind 或消息队列异步更新，降低写延迟。把这两类逻辑放在不同缓存模块中，能避免为保一致性牺牲整体吞吐。
- 余额类 key 使用 cache:balance:uid:2001 + 严格串行更新，防止并发覆盖
- 统计类 key 使用 cache:stat:post:7788:views + INCR + 过期后自动重建，允许短暂偏差
- 每个模块定义明确的更新契约：谁负责写、谁负责删、失败如何补偿
