QA

性能调优

Q：你提到在移动云盘项目中，针对Redis内存爆满和接口慢的问题，使用了Arthas进行分析。

请复述：你当时发现的具体异常调用链是什么？Arthas的哪个命令定位到了核心代码？最终除了优化索引，在代码层面或架构层面做了什么调整？

A：现象->链路拆解->根因定位->方案选型

1.定位现象，确定排查切入点

生产日志：有较多redis超50ms，无慢查询（慢查询配置100ms）。

初步猜测：redis连接数不够？redis数据结构不合理？高并发下redis集群主从的网络延时太高（延时高则缩短心跳时间）。

第一轮生产分布式压测，广告过滤（advfilter）接口响应时间部分超过100ms。

通过监控发现两点异常：一是Redis内存占用告警，二是业务接口整体耗时长。

2.Arthas链路分析

trace --skipJDKMethod false cn.xxx.advfilter.utils.RedisUtil get '#cost > 100'，发现RedisTemplate.execute 的耗时长。

继续深挖发现底层调用的是RedissonConnection，推断Redisson可能在特定版本下的连接池实现机制在高并发场景下存在竞争或阻塞。

建议：切换回Lettuce，从redis的耗时排查，部分超过100ms，不是问题主因。

3.深挖业务链路，锁定核心瓶颈

trace命令对doJudge方法下的多个处理器（如广告推荐、广告花名册等）进行耗时分析，发现Handler内部都涉及到了外部广告接口的调用。

当任意外部接口响应慢，累加效应导致整个接口超时（典型的“I/O密集型任务串行化” 导致的性能瓶颈）。

建议：非强关联的接口通过异步进行优化

代码层面重构：针对必须获取结果的多个外部接口，引入线程池（CompletableFuture）并发请求，将“串行等待”改为“并行等待”。

熔断与降级机制：针对广告位监控，一旦检测到某外部接口大量超时，立即触发熔断，返回默认兜底广告，防止拖垮核心云盘业务。