- 一致性哈希 + 本地缓存（提升命中率）
问题：普通二级缓存（本地 + Redis）在集群中因请求分散导致本地缓存命中率低、内存冗余。
方案：
客户端或网关层使用一致性哈希，将相同 Key 的请求路由到固定服务节点。
服务端优先查本地缓存 → 未命中再查 Redis → 最后回源数据库。
效果：热点数据本地命中率大幅提升，减少网络 IO 和序列化开销，性能提升约 40%。
注意：节点扩缩容时需处理哈希环漂移，可通过虚拟节点缓解缓存失效冲击。 - 本地缓存兜底（高可用容灾）
问题：Redis 故障时，大量请求直接打到数据库，可能导致雪崩。
方案：
正常状态：仅走 Redis，本地缓存不参与主链路。
降级状态（Redis 不可用）：自动切换为“先查本地缓存 → 再查库”，保护数据库。
恢复机制：Redis 恢复后，通过灰度切流 + 缓存预热避免冷启动。
价值：以牺牲部分数据时效性为代价，保障系统存活，体现高可用设计思维。 - 请求级别缓存（消除重复查询）
问题：单次请求内多个模块重复查询同一数据（如用户信息），造成资源浪费。
方案：
利用 Request-Scope 上下文（如 Spring Request Scope、Go context）缓存本次请求所需数据。
首次查询后存入上下文，后续模块直接复用。
优势：生命周期极短（<1秒），几乎无一致性风险，代码侵入小，收益显著。 - 会话级别缓存（高频读低频写场景）
适用场景：用户权限、配置等在一次会话中几乎不变的数据。
方案：
用户登录后加载数据至会话缓存（如 Session 或 Redis 中的会话结构）。
鉴权等操作优先读缓存。
通过监听权限变更消息队列，主动清除对应用户缓存，保证安全性。
特点：平衡性能与一致性，适合 RBAC 等后台系统。 - 客户端缓存（去中心化 & 隔离干扰）
问题：共享 Redis 易受“吵闹邻居”影响，热点数据被 LRU 淘汰。
方案：
调用方（Client）在本地缓存微服务返回结果，设置短 TTL（如 1 分钟）。
高级实现：由服务提供方封装带缓存逻辑的 SDK，SDK 订阅数据变更消息，主动失效本地缓存。
优势：隔离外部干扰，自主控制淘汰策略，降低微服务调用开销。 - 关联缓存预加载（业务驱动预热）
思想：基于用户行为预测，提前加载下一步所需数据。
案例：
用户“提交订单”后，大概率进入“支付页”。
在订单接口中异步预加载支付相关数据至缓存。
策略：设置较短过期时间（如 5 分钟），兼顾体验与资源消耗。 - 缓存预热与流量灰度（平滑上线）
问题：服务重启后本地缓存为空，全量流量导致缓存击穿。
方案：
启动预热：应用启动时加载字典、配置等热点数据。
流量灰度：新节点初始权重低，承接少量流量“暖机”，待缓存建立后再逐步提升至 100%。
价值：避免发布抖动，体现系统稳定性设计能力。
总结：缓存是系统工程
真正成熟的缓存架构不是单一技术堆砌，而是：
多级协同：本地 + 远程 + 请求/会话级缓存分层协作
场景适配：根据数据特征（读写频率、一致性要求）选择缓存策略
容灾兜底：具备降级、恢复、预热机制
业务融合：利用业务流程预加载，变被动为主动
核心理念：缓存设计的本质，是在性能、一致性、复杂度三者之间做精细化权衡。只有将缓存视为整体架构的一部分，才能构建出真正扛得住高并发冲击的系统。
网友评论