iis做网站,ui设计的一般流程,山东网站,中迅做网站是模板站吗感觉Redis变慢了#xff0c;这些可能的原因你查了没 #xff1f;(上) Redis 作为一款业内使用率最高的内存数据库#xff0c;其拥有非常高的性能#xff0c;单节点的QPS压测能达到18万以上。但也正因此如此#xff0c;当应用访问 Redis 时#xff0c;如果发现响应延迟变…感觉Redis变慢了这些可能的原因你查了没 (上) Redis 作为一款业内使用率最高的内存数据库其拥有非常高的性能单节点的QPS压测能达到18万以上。但也正因此如此当应用访问 Redis 时如果发现响应延迟变大时就会给业务带来非常大的影响。 比如在日常使用Redis时肯定或多或少都遇到过下面这种问题 大部分兄弟面对这种访问变慢问题的排查就会一头雾水不知道从哪里下手才好因为不理解 Redis 的架构体系、核心功能的实现原理甚至一些命令的使用限制等。 今天就可能引起Redis变慢的原因一一分析上篇看完后你将会形成一个比较完整的排查思路方案 Redis真的变慢了吗 当我们遇到服务响应比较慢时往往需要先排查内部原因先弄清楚是不是Redis服务导致的我们大部分系统可能涉及较长的链路和多服务、比如同一个接口会调用Mysql、MQ、Redis等其他三方组件和服务。 因此需要确定是不是访问Redis服务变慢进而拖慢了整个服务的响应变慢那就是先自查 • 应用服务访问Redis的请求记录下每次请求的响应延时对比是否响应变长 • 是否其他节点存在同样问题 假设我们确定了是Redis这条链路的问题如果不是Redis问题文章就写不下去啦哈哈这里同样存在两种可能 • 业务端请求到Redis服务网络是否存在问题存在网络延迟情况 • Redis服务端本身出现问题那需要进一步排查 正常来说网络存在问题的可能性还是比较小的因为如果存在网络问题那么其他服务同样都会发生网络延迟情况如果你想了解网络对 Redis 性能的影响可以用 iPerf 这样的工具测量从 Redis 客户端到服务器端的网络延迟如果这个延迟有几十毫秒甚至是几百毫秒就说明Redis 运行的网络环境中很可能有大流量的其他应用程序在运行。 好现在就剩下确定请求Redis的服务响应耗时变长了也是文章的要讲的焦点问题分析Redis变慢的原因先查看Redis的响应延迟可以对Redis 进行基准性能测试。 基准测试 基准性能就是指 Redis 在一台负载正常的机器上其最大的响应延迟和平均响应延迟分别是多少 但是这又不能把别人或者官方的测试结果作为参考的指标因为在不同的软硬件环境下它的性能表现差别特别大不同主频型号的CPU、不同的SSD硬盘都会极大影响Redis的性能表现。 那该以什么标准来认定Redis变慢呢 一般来说如果你观察到的 Redis 运行时延迟是其基线性能的 2 倍及以上就可以认定 Redis 变慢了 比如执行以下命令就可以测试出这个实例 60 秒内的最大响应延迟 可以看到此时的基线性能已经达到了 6.022ms如果响应延时为12ms那么基本可以认定为Redis变慢了当然我测试的机器性能比较差你们可以用自己的机器试试 注意这个命令只在Redis所在的服务器上运行避免网络对基线性能的影响只考虑服务端软硬件环境的影响 到这里已经确定了是Redis服务变慢那么是哪里变慢了呢接下来将进行更详细的说明 Redis性能影响要素 分析可能影响因素很重要是判断Redis性能的来源如下图 在排除了网络因素之后可以归纳为Redis自身命令操作、文件系统和操作系统三个大因素可能导致Redis性能存在问题。 接下来的文章将围绕这几个要素出发排查和解决性能影响问题 Redis性能问题分析 慢日志分析 日志是个好东西分析Mysql是否变慢我们可以通过查看慢日志的同样的分析Redis慢同样可以先看是否也存在慢日志 slowlog这是基础和直观的方式。 Redis 提供的慢日志命令的统计功能记录了有哪些命令在执行时耗时比较长快速定位问题。 需要配置的参数 • slowlog-log-slower-than 配置对执行时间大于多少微秒(microsecond, 1秒10^6微秒) 的命令进行记录。线上可以设置为1000微秒也就是1毫秒。 • slowlog-max-len 设置最大考验记录多少条记录。slow log 本身是一个先进先出(FIFO) 队列当队列大小超过该配置的值时最旧的一条日志将被删除。线上可以设置为1000以上。 配置如下 //命令执行耗时超过 10 毫秒记录慢日志 CONFIG SET slowlog-log-slower-than 10000//只保留最近 500 条慢日志 CONFIG SET slowlog-max-len 500我们看下慢日志如何查询 127.0.0.1:6379 SLOWLOG get 3 1) (integer) 32693 # 慢日志ID 2) (integer) 1593763337 # 执行时间戳 3) (integer) 5299 # 执行耗时(微秒) 4) 1) LRANGE # 具体执行的命令和参数2) user_list:20003) 04) -1注意慢日志功能比较粗糙简单没有持久化记录能力都是记录在内存中没有持久化到文件中所以一般都是设置保留有限的慢命令条数如果慢命令比较多会存在不能全部记录的情况 常见集中导致Redis变慢不合理的命令使用方式 • 获取Redis中的key时避免使用keys * • 高频使用了 O(N) 及以上复杂度的命令例如SUNION、SORT、ZUNIONSTORE、ZINTERSTORE 聚合类命令 • O(N) 复杂度的命令但 N 的值非常大比如hgetall、smembers、lrange、zrange等命令 这种情况下我们可以将复杂的聚合放在业务端处理并且每次尽量少获取大量数据 BigKey问题 分析慢日志时发现很多请求并不是复杂度高的命令都是一些del、set、hset等的低复杂度命令那么就要评估是否写入了大key也就是BigKey。 Bigkey 是指当 Redis 的字符串类型过大非字符串类型元素过多 (hashlistset等存储中value值过多) bigkey会带来如下问题 1.数据请求大量超时 redis是单线程的当一个key数据响应的久一点就会造成后续请求频繁超时。如果服务容灾措施考虑得不够会引发更大的问题。 2.侵占带宽网络拥堵 当一个key所占空间过大多次请求就会占用较大的带宽直接影响服务的正常运行。 3.内存溢出或处理阻塞 当一个较大的key存在时持续新增key所占内存会越来越大严重时会导致内存数据溢出当key过期需要删除时由于数据量过大可能发生主库较响应时间过长主从数据同步异常删除掉的数据从库还在使用。 此时我们可以回想和检查业务代码查看是否存在写入bigkey的情况评估好单个key的数据大小避免存在过大数据。 除了代码自查之外可以使用命令查如下 # redis-cli -h 127.0.0.1 -p 6379 --bigkeys-------- summary -------Sampled 15 keys in the keyspace! Total key length in bytes is 162 (avg len 10.80) //最大的数据值 Biggest string found page4:20230921 has 12304 bytes Biggest list found article:100 has 8 items Biggest set found union:65:67 has 7 members Biggest hash found page2:20230921 has 2 fields Biggest zset found likeTopList has 2 members //平均值 6 strings with 24778 bytes (40.00% of keys, avg size 4129.67) 1 lists with 8 items (06.67% of keys, avg size 8.00) 6 sets with 24 members (40.00% of keys, avg size 4.00) 1 hashs with 2 fields (06.67% of keys, avg size 2.00) 1 zsets with 2 members (06.67% of keys, avg size 2.00)–i 参数降低扫描的执行速度比如 --i 0.1 表示 100 毫秒执行一次降低扫描过程中对 Redis运行实例的影响。 –bigkeys命令原理解析 Redis 在内部执行了 SCAN 命令遍历整个实例中所有的 key 然后针对 key 的类型分别执行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令来获取 String 类型的长度、容器类型List、Hash、Set、ZSet的元素个数 面对bigkey问题我们可以这些方面下手去处理 对大Key进行拆分 优化使用删除Key的命令可使用异步删除 unlink 命令删除缓存 尽量不写入大Key 合理使用批处理命令 key集中过期 不知道大家是否遇到过在某个时间点Redis突然出现一波延时而且报慢的有时候超时还有时间规律 如果出现这种情况就需要考虑是否存在大量key集中过期的情况因为大量的key在某个固定时间点集中过期在这个时间点访问Redis时就有可能导致延迟增加。 如果出现了这种情况那么需要从两个方面排查一下 • 业务逻辑是否有定时任务的脚本程序定期操作key • Redis的Key数量出现集中过期清理 程序层面这个我们自己排查就好了这里主要看下为什么Key数量集中过期集中过期为啥造成了Redis访问变慢 Redis的Key过期策略是怎样的 被动过期只有应用发起访问某个key 时才判断这个key是否已过期如果已过期则从Redis中删除 主动过期在Redis 内部维护了一个定时任务默认每隔 100 毫秒1秒10次从全局的过期哈希表中随机取出 20 个 key判断然后删除其中过期的 key如果过期 key 的比例超过了 25%则继续重复此过程直到过期 key 的比例下降到 25% 以下或者这次任务的执行耗时超过了 25 毫秒才会退出循环 注意这个主动过期 key 的定时任务是在 Redis 主线程中执行的 这也是我们主要关注的问题 【主动过期清理】那为什么会导致Redis延时呢 因为主动过期是在Redis 主线程中执行的也就意味着会阻塞正常的请求命令。 进一步说就是如果在执行主动过期的过程中出现了需要大量删除过期 key 的请求那么此时应用程序在访问 Redis 时必须要等待这个过期任务执行结束Redis 才可以继续处理新请求这也就是为什么此时访问Redis会突然出现延迟。 即使删除过期key是耗时的也不会记录在slowlog慢日志中哦 这里大家估计又有疑惑了这不是慢了吗 别急这是因为slowlog记录的是Redis服务端在命令执行前后计算每条命令的执行时长而过期清理的时候Redis是登录状态还不能处理客户端发过来的请求也就是在命令执行之前进行的。 这种情况我们可以这样处理 • 业务Key设置过期时间时加上一个随机过期时间段比如1分钟 • 通过执行info命令获取过期Key数量【expired_keys】的统计值 • Redis 4.0以上版本开启 lazy-free 机制把释放内存的操作放到后台线程中执行避免阻塞主线程 预估内存不足 我们知道服务器的内存是有限的这个是既定事实而且使用Redis时都会配置当前实例可用的最大内存maxmemory和数据自动淘汰策略 maxmemory : 默认为0 不限制。 //获取maxmemory配置的大小 127.0.0.1:6379 config get maxmemory 1) maxmemory 2) 0 //默认值是0//可以在redis.conf中配置 maxmemory 1024mb 当使用的内存达到了 maxmemory 后即使配置了自动淘汰策略仍然会在之后每次写入新数据时操作延迟都会变长。 原因在于当 Redis 内存达到 maxmemory 后每次写入新的数据之前Redis 必须先从实例中踢出一部分数据让整个实例的内存维持在 maxmemory 之下然后才能把新数据写进来。 Redis的常用 allkeys-lru / volatile-lru 的淘汰策略 volatile-lru 利用LRU算法移除设置过过期时间的key allkeys-lru 利用LRU算法移除任何key 和上一个相比删除的key包括设置过期时间和不设置过期时间的 Redis采用近似LRU算法实现逻辑是什么样的 1每次从实例中随机选择一个key (样本集)并从样本集中挑选最长时间未使用的 key 淘汰剩下的放入待淘汰池 2再次随机获取一批样本集并与第一步池子的key比较进而进行淘汰最少访问的key剩下的放入待淘汰池 3循环往复上面两个操作步骤直到实例内存降到maxmemory值为止 假如我们淘汰策略删除的是 bigkey那么耗时还更久可想而知 bigkey对Redis的危害应该很大 不过针对内存不足问题我们也可以进行一个优化措施 1避免存储 bigkey降低释放内存的耗时 2合理预估内存占用避免达到内存的使用上限 • 根据写入Key的类型、数量及平均大小计算预估 • 写入一小部分比例的真实业务数据然后进行预估 3Redis 4.0 及以上版本开启 layz-free 机制把淘汰 key 释放内存的操作放到后台线程中执行 实际请求量超预期 一个系统处理请求是有上限的。Redis虽然处理速度很快但是也有上限。因此在流量暴增的时候会比较快达到Redis的处理瓶颈这个时候整个系统也会变慢出现slowlog等。 这个现象也比较好观察可以看看实例的cpu情况如果持续100%基本可以判定达到处理上限了。 这种情况最好我们要结合云监控对CPU使用率、访问的QPS进行监控发现系统瓶颈看是否进行扩容和调整。