分布式缓存架构设计：多级缓存与缓存一致性

## 多级缓存架构设计原则 多级缓存通过不同层次设置缓存减少后端数据源直接访问。三级架构：本地缓存（Caffeine/Go BigCache进程内延迟纳秒到微秒级但容量有限且集群不共享）；分布式缓存（Redis毫秒级大容量支持多种数据结构集群共享）；CDN缓存（网络边缘节点适合读多写少地域分布广的静态资源和API响应）。Caffeine基于Window TinyLfu淘汰算法在命中率和内存效率上均优于传统LRU/LFU算法。Redis支持String/Hash/List/Set/ZSet/Stream等数据结构灵活应对不同场景。读取采用逐级穿透：先查本地缓存，未命中查Redis，仍未命中回源数据库并逐级回填。每级缓存根据特性设置合理过期策略和容量限制。 ## 缓存一致性与数据同步 Cache-Aside Pattern最常用：读先查缓存未命中查DB将结果写入缓存设TTL；写先更新DB再删除缓存而非更新——选择删除因并发写场景下先更新缓存再更新DB可能导致不一致。双写一致性保障策略：延迟双删——更新DB前先删缓存，更新DB后延迟一定时间再删一次确保并发读取不会将旧数据回填。消息队列方案——将缓存失效事件发布到MQ由消费者异步删除缓存保证最终一致性。Canal方案——监听MySQL Binlog当数据变更时自动触发缓存失效对业务代码零侵入。极端场景DB更新成功但缓存删除失败需重试机制或定时对账任务兜底。设计时需根据业务对一致性的容忍度选择策略强弱。 ## 高可用集群与性能调优 Redis Cluster将数据分16384个哈希槽，每个主节点至少配一个从节点。主故障集群通过选举自动提升从节点保证可用性。Sentinel适合单实例高可用但不支持分片。内存管理：maxmemory设上限，淘汰策略推荐allkeys-lru或volatile-lru根据场景选择。大Value建议应用层用GZIP/LZ4压缩减少内存和网络开销。Pipeline批量执行多条命令减少网络往返显著提升吞吐。SCAN替代KEYS遍历避免阻塞主线程。客户端连接池合理设置最大连接数和超时参数。缓存预热在系统启动或大面积失效时提前加载热点数据防止雪崩。热点Key问题可通过本地缓存或Redis集群分片缓解。监控覆盖缓存命中率、Key数量、内存使用和连接数。