摘要
随着企业协同办公系统用户规模与并发请求量持续增长，作为核心支撑的用户中心系统面临高并发查询、数据库压力过载、通讯录同步缓慢、服务 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主从哨兵高可用等。
三、项目如何设计分布式缓存及应用
（一）缓存架构设计与技术选型
通过调研，我选择基于业界开源分布式多级缓存开源框架Jetcache，Redis使用集群模式，开启AOF+RDB混合持久化；Caffeine作为本地缓存，缓存基础信息以及可见性信息；Mysql主从作为数据源。数据访问流程：应用层->本地缓存->Redis Cluster -> Mysql。选型理由Redis Cluster原生高可用+自动故障转移、Caffeine本地缓存性能优于Guava Cache、Mysql主从满足读多写少场景，服务架构如下：
其中，通过rocketmq进行应用集群本地实例缓存更新；通过定时任务每天更新全量缓存数据，保障最终一致性；通过prometheus+grafana进行缓存相关指标的展示
（二）缓存数据建模
项目中根据访问模式以及数据特点设计缓存模型与对应的数据结构，将整个组织架构拆分为四大模块信息：员工+部门基本信息、员工+部门可见性信息、员工动态信息（工作状态、头像昵称等信息）以及机器人完整信息，不同模块数据走不同接口分开同步。采用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%以上
四、实施效果与经验总结
在项目中，我通过分析访问模式以及业务数据特点，设计不同的缓存模型，基于业界开源缓存框架进行分布式多级缓存设计来统一承载系统数据读写需求，结合多级架构、读写策略、一致性方案、穿透击穿雪崩保护等策略，同时搭建对应的监控大盘与告警，完成从设计到落地的闭环验证。实践表明，该方案能够在读多写少、高并发压力的场景中大幅提升性能与稳定性，为后续业务扩展与架构演进提供可复用的工程模板与经验，同时我在部门内部进行分享，并成功复用到其他业务场景中。