优化背景

项目使用Thymeleaf模板引擎动态渲染页面，分类树作为基础功能，初期采用直接查询数据库的方式快速上线，但随着数据量增长，性能问题逐渐暴露。

第一次优化：引入Redis缓存问题：Dev环境分类数据增多后出现性能瓶颈。方案：增加Redis缓存层，查询时先读Redis，若无数据则查数据库并写入Redis（缓存5分钟）。效果：暂时缓解性能问题，完成联调测试。对应流程图：

第二次优化：Job异步更新Redis问题：St环境首页间歇性访问缓慢，因缓存过期后大量请求穿透到数据库。方案：增加定时Job（每5分钟）异步更新Redis数据，保留缓存穿透逻辑作为容错，Redis改为永久缓存。效果：解决稳定性问题，避免缓存过期引发的性能波动。对应流程图：

第三次优化：增加本地缓存问题：压力测试显示QPS仅100+，Redis成为瓶颈。方案：引入Caffeine作为本地缓存，优先读本地缓存，未命中则读Redis（更新到本地），极端情况降级查数据库。关键点：本地缓存设5分钟过期，容忍短期数据不一致（分类数据低频变更）。效果：QPS提升至500+，满足上线要求。对应流程图：

第四次优化：数据压缩传输问题：运营积累大量分类数据，接口返回数据达1MB，首页加载变慢。方案：开启Nginx的GZip压缩功能，将返回数据从1MB压缩至100KB。效果：传输效率提升10倍，缓解网络延迟。第五次优化：Redis数据瘦身与压缩问题：Redis中大Key（分类树）引发存储压力。方案：字段精简：去除非必要字段（如inDate、inUserId等）；字段名缩短：通过@JsonProperty注解映射为短字段名（如id→i）；存储压缩：将JSON字符串转为GZip压缩后的byte数组存入Redis。效果：Redis存储空间减少10倍，解决大Key问题。总结

五次优化逐步解决了不同阶段的性能瓶颈：

缓存引入（Redis）→ 2. 异步更新（Job）→ 3. 多级缓存（本地+Redis）→ 4. 传输优化（GZip）→ 5. 存储优化（数据瘦身+压缩）。最终在保证功能的前提下，显著提升了系统的吞吐量、稳定性和资源利用率。