怎么排查SpringBoot的Redis慢查询_用AOP拦截记日志

RedisTemplate执行慢的根因在客户端，需用AOP拦截execute()等方法分段计时，聚焦连接获取、序列化、命令执行三阶段耗时，并按命令类型分级设阈值（如GET/SET为20ms、SCAN为500ms），避免误报。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么RedisTemplate执行慢但没报错

在Spring Boot项目里，你有没有遇到过这种情况：用RedisTemplate操作Redis时，偶尔会卡顿几秒，但用redis-cli --latency去测服务端，延迟却显示正常。这其实是一个明确的信号：问题大概率出在客户端这一侧。

背后的原因，无非是连接池阻塞、序列化耗时、命令堆积或者网络抖动。这里有个常见的误区，以为靠@EventListener监听RedisConnectionFailureException就能抓到所有问题。实际上，这种“慢而不崩”的情况，异常监听器是捕不到的，必须得主动出击，去测量耗时才能定位。

用AOP拦截RedisTemplate的execute方法最准

想要精准测量，就得找到那个“必经之路”。RedisTemplate的所有读写操作，最终都会落到execute()或executePipelined()这几个底层方法上。比起去拦截opsForValue().get()这类封装好的方法，直接切入execute()更底层，覆盖也更全面。不过要注意，一般别去拦截executeWithStickyConnection()，那是集群模式下的专用方法，普通场景用不到。

具体怎么操作呢？这里有几个实操建议：

• 切面表达式要写准：建议用@Around(“execution(* org.springframework.data.redis.core.RedisTemplate.execute*(..))”)，这样能把execute、executePipelined、executeReadOnly都覆盖住。
• 排除干扰方法：像getConnection()和closeConnection()这类方法，本身不发送命令，拦截了反而会干扰判断，应该排除掉。
• 日志信息要详尽：在日志里，务必记清楚method.getName()和args[0]。后者代表了RedisCallback的实际执行逻辑，能帮你判断这次调用是否包含了scan这类游标操作，这对后续分析至关重要。

怎么定义“慢”并避免日志刷爆

接下来是关键问题：到底多久算“慢”？如果简单地设置一个固定阈值，比如超过100毫秒就报警，很容易产生误报。道理很简单，一个SCAN命令扫描百万级的key，耗时500毫秒可能也属正常；而一个简单的GET命令如果花了50毫秒，那就非常可疑了。

所以，更科学的做法是根据命令类型进行分级设阈：

• 单key命令：像GET、SET、DEL这类，阈值可以设得严格些，比如20毫秒。
• 批量命令：像HGETALL、LRANGE这类可能返回大量数据的操作，阈值可以放宽到100毫秒。
• 扫描/聚合命令：像SCAN、SUNION这类，本身耗时就长，阈值可以设为500毫秒，并且在日志里额外打上isScan:true这样的标签，方便区分。

还有一点很重要，超时日志建议只打到ERROR级别，并且一定要加上条件判断：if (duration > threshold) { log.error(...) }。千万别用WARN级别，否则日志很容易被刷爆，真正有用的信息反而被淹没了。

别漏掉连接获取和序列化这两块耗时

然而，只拦截execute()方法，测量的只是“命令执行+响应解析”这个阶段的耗时。但慢查询的“罪魁祸首”，可能藏在更前面的两个环节：从连接池获取连接，以及将Ja va对象序列化成字节数组。

因此，我们需要更精细的埋点，用StopWatch把整个过程分成三段来计时：

1. 从尝试获取连接开始，到成功拿到连接为止。
2. 从序列化开始，到调用execute()方法之前。
3. 从execute()方法返回后，到反序列化完成。

这三段耗时指向不同的问题：

• 如果第一段（获取连接）耗时高，就该去检查连接池配置了，比如lettuce.pool.max-idle和min-idle是不是设置得过小，导致连接争抢。
• 如果第二段（序列化）耗时高，那很可能是默认的JdkSerializationRedisSerializer效率太低，可以考虑换成GenericJackson2JsonRedisSerializer。

最后还得提个醒：如果你用的是Lettuce客户端，它默认是异步的。AOP拦截到的execute()返回的其实是一个Future，这个耗时仅仅是提交任务的耗时，并非命令真正执行完的耗时。要想测准，得用future.get(timeout, TimeUnit)，但这会阻塞线程，使用时需要权衡。

说到底，真实的性能瓶颈，往往卡在序列化或者连接池争抢上，而不是Redis服务本身。所以，打日志时把这三段耗时分开记录，远比只记一个总时间要有用得多。