记一次应用访问Redis超时的案例分析

本文涉及的产品
应用实时监控服务-应用监控,每月50GB免费额度
函数计算FC,每月15万CU 3个月
性能测试 PTS,5000VUM额度
简介: 记一次应用访问Redis超时的案例分析

问题描述

某产品线应用访问Redis出现超时(超时时间配置的是2000ms),异常信息:

分析过程

查看监控数据

通过监控数据,了解应用运行状态以确定应用出现问题时间点、是否过载、依赖服务是否过载等基本信息。

系统监控指标

CPU、内存、Load、磁盘指标数据都是正常的,所以系统资源是足够的。

JVM监控指标

FullGC过于频繁及耗时较长的情况下会造成应用阻塞住,从图中看FullGC发生的频次是正常的,一次FullGC耗时也是正常的,所以FullGC不是造成SocketTimeoutException的原因。

Redis监控指标

从Redis控制台及阿里云杜康上该Redis实例的CPU使用率、内存使用率等指标都是正常的。

分析应用异常

分析异常日志,首先需要弄明白的是应用抛异常时候执行的业务逻辑及异常本身含义;异常在本机出现的频次情况,是否存在规律性;及异常在该应用的集群上的规律性。

除了访问Redis异常,应用依赖得其他服务没有超时情况。

单机异常规律

分析了每小时、每分钟及每秒钟异常出现的次数,发现异常具有一定周期性:每个小时在固定的几个时间点会集中出现,出现的时候会集中在相邻的几秒钟内。

集群异常规律

统计了应用集群中其他机器的异常规律,每台机器出现异常的规律是一致的:不出现都不出现,要出现一起出现。

统计超时的key

我们统计了异常日志中,所有超时的key,然后单独访问这些key,并没有任何发生超时的情况。

初步结论

通过上面的分析,很有可能是应用侧在相对集中的时间点访问了同一个Redis节点,在该Redis节点产生了慢查询,进而阻塞掉了正常的请求Redis的命令。

验证结论

访问Redis链路

slowlog

最先想到是Redis慢查询,有些应用卡慢的场景到这里可以找到线索,遗憾的是slowlog并没有看到应用端发过来的命令。

Redis单节点info all

接着是Redis单节点的监控指标,一些CPU高、卡慢的场景在这里找到线索,经过对比确实有个节点avgRT比其他节点高很多。下面是两个不同节点的数据:

avgRT=45的是节点8,初步判定节点8是问题节点。

定位redis节点

我们初步判定节点8是问题节点,超时的key是否打到了这个节点呢?阿里云redis自研了info key指令:查询key所属的slot和db。

可惜的是这个版本的Redis返回的node_index跟控制台上实例拓扑图的node index不一致。

我们只好去每个Redis节点通过tcpdump抓包,对抓包里的key执行info key <biz_key>来核对node_index:5到底是哪个节点,最终定位到了超时key都是打在了节点13.

定位异常key

是对哪些key的访问阻塞住了Redis,进而造成其他命令的超时呢?首先想到的是大key的影响。

bigkeys

tcpdump定位大key影响

  • 在redis节点132进行tcpdump抓包且过滤大key
tcpdump -i any tcp and dst port 3048 -A -nn | grep -E '大key1|大key2|大key3|......'
  • 在应用侧过滤日志中的异常信息
tail -f error.log | grep 'SocketTimeoutException'

当应用侧出现SocketTimeoutException的时候,redis节点上的key是需要我们引起关注的,最后将定位的key提供给研发。

经验总结

排查此类问题,几个需要关注的点

  • 统计超时key,及key对应的redis节点
  • Redis slowlog慢查询
  • Redis单节点info all指标对比不同节点服务情况
  • Redis bigkeys
  • 还有一个注意的点是Redis hotkeys
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
6天前
|
canal NoSQL 关系型数据库
Redis应用—7.大Value处理方案
本文介绍了一种用于监控Redis大key的方案设计及其实现步骤。主要内容包括:方案设计、安装与配置环境、binlog数据消费者。
Redis应用—7.大Value处理方案
|
6天前
|
缓存 NoSQL Java
Redis应用—6.热key探测设计与实践
热key问题在高并发系统中可能导致数据层和服务层的严重瓶颈,如Redis集群瘫痪和用户体验下降。为解决此问题,京东开发了JdHotkey热key探测框架,具备实时性、准确性、集群一致性和高性能等特点。该框架由etcd集群、Client端jar包、Worker端集群和Dashboard控制台组成,通过分布式计算快速识别热key并推送至应用内存,有效减轻数据层负载,提升服务性能。JdHotkey适用于多种场景,安装部署简便,支持毫秒级热key探测和集群一致性维护。
Redis应用—6.热key探测设计与实践
|
5天前
|
缓存 NoSQL Java
Redis应用—8.相关的缓存框架
本文介绍了Ehcache和Guava Cache两个缓存框架及其使用方法,以及如何自定义缓存。主要内容包括:Ehcache缓存框架、Guava Cache缓存框架、自定义缓存。总结:Ehcache适合用作本地缓存或与Redis结合使用,Guava Cache则提供了更灵活的缓存管理和更高的并发性能。自定义缓存可以根据具体需求选择不同的数据结构和引用类型来实现特定的缓存策略。
Redis应用—8.相关的缓存框架
|
4天前
|
缓存 NoSQL Java
Redis应用—9.简单应用汇总
本文主要介绍了Redis的一些简单应用。
|
1月前
|
缓存 NoSQL 中间件
Redis,分布式缓存演化之路
本文介绍了基于Redis的分布式缓存演化,探讨了分布式锁和缓存一致性问题及其解决方案。首先分析了本地缓存和分布式缓存的区别与优劣,接着深入讲解了分布式远程缓存带来的并发、缓存失效(穿透、雪崩、击穿)等问题及应对策略。文章还详细描述了如何使用Redis实现分布式锁,确保高并发场景下的数据一致性和系统稳定性。最后,通过双写模式和失效模式讨论了缓存一致性问题,并提出了多种解决方案,如引入Canal中间件等。希望这些内容能为读者在设计分布式缓存系统时提供有价值的参考。感谢您的阅读!
130 6
Redis,分布式缓存演化之路
|
3月前
|
存储 缓存 NoSQL
解决Redis缓存数据类型丢失问题
解决Redis缓存数据类型丢失问题
206 85
|
1天前
|
存储 缓存 NoSQL
Redis缓存设计与性能优化
Redis缓存设计与性能优化涵盖缓存穿透、击穿、雪崩及热点key重建等问题。针对缓存穿透,可采用缓存空对象或布隆过滤器;缓存击穿通过随机设置过期时间避免集中失效;缓存雪崩需确保高可用性并使用限流熔断组件;热点key重建利用互斥锁防止大量线程同时操作。此外,开发规范强调键值设计、命令使用和客户端配置优化,如避免bigkey、合理使用批量操作和连接池管理。系统内核参数如vm.swappiness、vm.overcommit_memory及文件句柄数的优化也至关重要。慢查询日志帮助监控性能瓶颈。
24 9
|
2月前
|
存储 缓存 NoSQL
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
|
2月前
|
缓存 NoSQL 关系型数据库
云端问道21期实操教学-应对高并发,利用云数据库 Tair(兼容 Redis®)缓存实现极速响应
本文介绍了如何通过云端问道21期实操教学,利用云数据库 Tair(兼容 Redis®)缓存实现高并发场景下的极速响应。主要内容分为四部分:方案概览、部署准备、一键部署和完成及清理。方案概览中,展示了如何使用 Redis 提升业务性能,降低响应时间;部署准备介绍了账号注册与充值步骤;一键部署详细讲解了创建 ECS、RDS 和 Redis 实例的过程;最后,通过对比测试验证了 Redis 缓存的有效性,并指导用户清理资源以避免额外费用。