摘要随着企业协同办公系统用户规模与并发请求量持续增长作为核心支撑的用户中心系统面临高并发查询、数据库压力过载、通讯录同步缓慢、服务 CPU 与内存频繁告警等性能瓶颈。本人在项目中担任系统架构师负责用户中心分布式多级缓存架构的选型、设计、落地与优化工作重点完成缓存数据建模、读写策略、一致性保障、缓存穿透 / 击穿 / 雪崩防护等关键技术并针对开源 JetCache 本地缓存同步机制缺陷采用 RocketMQ 替代 Redis Pub/Sub 实现可靠同步与可观测性增强。项目上线后基础信息查询接口平均响应时间从 200ms 降至 15ms通讯录同步接口从 2s 降至 200ms缓存命中率达 95% 以上服务运行稳定无异常告警有效支撑高并发场景下的业务连续性与扩展性。本次实践形成的多级缓存设计模板已在公司部门多个业务系统成功复用为同类高并发读多写少场景提供了可参考的架构解决方案。正文一、项目背景与本人职责用户中心系统是企业协同办公平台的核心基础服务负责统一管理组织架构、员工信息、部门关系、通讯录可见性等核心数据为即时通讯、邮箱、OA 审批等上层应用提供低延迟、高可用的数据查询与同步能力。其中通讯录可见性数据是指为了满足公司安全和保密性需要不同员工看到的通讯录组织架构都不一样千人千面同时管理人员可以在后台配置对应可见性规则。其中一条主核心流程为管理员人员调整组织架构-重新计算人员可见性-发送信令同步客户端-客户端拉取通讯录数据到本地。既有架构依赖MySQL集群部分数据也进行了Redis缓存但是缓存设计粗粒度导致频繁更新缓存。同时当有较大组织架构调整时客户端全部重新拉取通讯录数据实时计算可见性经常出现服务CPU与内存告警接口性能急剧下降严重影响办公体验与系统稳定性。本人在该项目中担任系统架构师核心职责包括牵头完成分布式缓存技术选型与整体架构设计定义缓存数据模型、键规范、过期策略与读写流程设计缓存一致性方案与高可用防护机制优化开源框架 JetCache 本地缓存同步逻辑制定压测方案、灰度上线策略与监控告警体系保障项目从设计到落地全流程稳定推进。二、分布式缓存理论与设计原则一主流缓存架构模式1.客户端分片应用层维护节点列表与一致性哈希灵活度高但需自行处理故障转移与扩缩容运维成本高。2.代理分片通过 Twemproxy、Codis 等中间件统一代理后端 Redis 节点对应用透明但代理易成为性能瓶颈与单点故障。3.服务端分片以 Redis Cluster 为代表原生支持数据自动分片、主从复制、故障转移与扩缩容具备高可用、高性能、易运维等优势是大规模分布式缓存首选方案。本项目采用三级缓存架构L1 本地缓存 Caffeine→L2 远端缓存 Redis Cluster→L3 数据源 MySQL 主从兼顾性能、一致性与可用性。二缓存读写策略常见的几种缓存读写策略包括1.Cache Aside旁路缓存读取时先查询缓存未命中则查询数据库再回填缓存写时先更新数据库再删除缓存。优点是实现简单适用面广缺点是短暂的不一致窗口。2.Read/Write Through穿透缓存作为唯一入口由缓存层负责同步数据库保证强一致性但实现复杂。3.Write Behand异步写回写操作只更新缓存、异步批量刷数据库性能最优但可能丢数据结合用户中心业务特点一是读远多于写尤其是员工、部门等基础信息因此针对此类信息基于Cache Aside的基础上针对写进行调整改为直接更新缓存二是可见性缓存计算复杂由基础缓存计算而来而且无法较好的判断出来组织架构比如部门变更会影响哪些人的可见性因此针对此部分数据采用Cache Aside模式更新数据库后删除缓存。三一致性保障方案1.应用直更模式数据更新后由业务代码主动更新缓存一致性好、延迟低。2.消息队列模式数据变更投递消息消费者异步更新缓存解耦业务与缓存。3.Binlog 订阅模式通过 Canal 解析 MySQL 日志触发缓存更新无侵入、通用性强。本项目采用应用直更消息队列定时任务兜底的混合方案基础数据直更缓存可见性数据删除缓存并通过消息广播每日全量刷新保障最终一致性。四缓存常见问题与防护1.缓存穿透是指查询不存在数据打穿缓存常见的措施有布隆过滤器Bloom Filter前置判断、缓存空对象null值设置较短的TTL、参数校验拦截非法请求。2.缓存击穿是指热点key过期瞬间大量请求打DB可以采用互斥锁分布式锁保证只有一个请求查DB、其他请求等待热点数据永不过期后台线程异步更新。3.缓存雪崩指大量Key同时过期或Redis宕机常见的措施有过期时间随机化、多级缓存本地兜底、限流降级保护数据库、Redis主从哨兵高可用等。三、项目如何设计分布式缓存及应用一缓存架构设计与技术选型通过调研我选择基于业界开源分布式多级缓存开源框架JetcacheRedis使用集群模式开启AOFRDB混合持久化Caffeine作为本地缓存缓存基础信息以及可见性信息Mysql主从作为数据源。数据访问流程应用层-本地缓存-Redis Cluster - Mysql。选型理由Redis Cluster原生高可用自动故障转移、Caffeine本地缓存性能优于Guava Cache、Mysql主从满足读多写少场景服务架构如下其中通过rocketmq进行应用集群本地实例缓存更新通过定时任务每天更新全量缓存数据保障最终一致性通过prometheusgrafana进行缓存相关指标的展示二缓存数据建模项目中根据访问模式以及数据特点设计缓存模型与对应的数据结构将整个组织架构拆分为四大模块信息员工部门基本信息、员工部门可见性信息、员工动态信息工作状态、头像昵称等信息以及机器人完整信息不同模块数据走不同接口分开同步。采用Hash结构进行存储同时统一缓存键规范{环境}{业务域}{租户id}_{userId}例如 prod_staff_2_1001来支持多租户以及预发和线上缓存隔离。针对端上数据同步针对这几类信息增加对应的版本缓存采用zset存储更新时间戳作为score客户端保存本地各类信息的最大版本号时间戳当服务端有数据更新时客户端增量同步时只需要从zset中捞取score比客户端版本大的数据。缓存过期时间设置为26小时大于1天同时每天凌晨全量更新基础数据缓存从而保证基础缓存数据永不过期以及最终一致性。三缓存写入策略与更新流程基础数据写入路径员工修改昵称-更新员工信息表mysql-更新员工动态信息缓存-Jetcache广播其他实例更新本地缓存组织架构变更管理人员调整部门-更新部门信息表mysql-删除涉及的可见性信息缓存-Jetcache广播其他实例删除本地缓存缓存预热由于基础数据比如员工或者部门信息的变化频率低同时查询频率高因此在服务启动时结合Spring容器启动事件监听器触发一次客户端全量同步组织架构数据逻辑将基础信息加载到本地与远端缓存避免冷启动雪崩四穿透击穿雪崩防护实践我在项目中通过Null值策略相对于布隆过滤器方案实现简单来避免缓存穿透。通过设置缓存数据有效期同时在缓存有效期内通过定时任务每天更新缓存实现缓存永不过期来避免可能出现的击穿与雪崩问题五开源Jetcache本地实例缓存同步优化开源jetcache对于不同实例本地缓存的同步默认采用的是Redis提供的发布-订阅pub-sub但是这种方案有几个缺点一是无持久化当服务在发布的时候存在消息丢失从而导致本地缓存不一致二是无法监控到本地缓存更新的相关指标比如更新延迟、吞吐量等等因此在熟悉开源代码后对本地实例同步部分进行改造采用rocketmq来实现本地实例的同步同时增加了本地实例同步相关的监控指标。六监控告警我在项目中结合Prometheus Grafana进行埋点上报指标同时Jetcache本身也提供了本地与远端缓存命中率等相关指标采集本地缓存消息平均延迟、本地缓存命中率、远端缓存命中率等指标针对指标配置对应告警阈值。针对Redis与数据库配置对应的主从延迟以及内存使用率等告警通知。七灰度上线与性能验证压测我采用jmeter模拟不同员工来同步通讯录数据验证缓存命中率以及接口延迟与QPS。灰度服务改造后提供新接口同时针对组织架构通讯录同步新发版的客户端使用新接口实现灰度测试效果通过观察压测结果以及监控指标基础信息查询接口响应时间平均rt从200ms降低到15ms通讯录同步接口平均rt从2s降低到200ms单机8c16g服务器30个并发qps在400左右达到预期目标。同时本地缓存命中率在95%以上四、实施效果与经验总结在项目中我通过分析访问模式以及业务数据特点设计不同的缓存模型基于业界开源缓存框架进行分布式多级缓存设计来统一承载系统数据读写需求结合多级架构、读写策略、一致性方案、穿透击穿雪崩保护等策略同时搭建对应的监控大盘与告警完成从设计到落地的闭环验证。实践表明该方案能够在读多写少、高并发压力的场景中大幅提升性能与稳定性为后续业务扩展与架构演进提供可复用的工程模板与经验同时我在部门内部进行分享并成功复用到其他业务场景中。