redis 性能优化二

这篇具有很好参考价值的文章主要介绍了redis 性能优化二。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

性能优化的第二篇文章,将重点讲一下Redis 的响应延迟,响应延迟如何对redis 进行优化。这个延迟不是说一个命令或者几个命令变慢了,延迟了几秒,就说Redis 变慢了。在不同的软硬件环境下,Redis 本身的绝对性能并不相同。要根据Redis 的基线性能做判断。所谓的基线性能呢,也就是一个系统在低压力、无干扰下的基本性能,这个性能只由当前的软硬件配置决定。

怎么确定基线性能呢?可以用下面这个方法:

redis 性能优化二,redis,redis,性能优化,数据库,redis 性能优化

实际上,从 2.8.7 版本开始,redis-cli 命令提供了–intrinsic-latency 选项,可以用来监测和统计测试期间内的最大延迟,这个延迟可以作为 Redis 的基线性能。其中,测试时长可以用–intrinsic-latency 选项的参数来指定。

我们运行上面的命令,该命令可以打印出120秒内监测到的最大延迟。根据图可以看到,最大延迟是 26402 microseconds(微秒),那么我们的基线性能为 26402 microseconds(微秒)。需要注意的是基线性能和当前操作系统与硬件配置有关,所以我们可以把它和Redis运行时的延迟结合起来,进一步判断,Redis 性能是否变慢了。

这个数据有点大,是在我本地机器上测试的,所以对于我的机器来说,只要命令不是高于基准测试的2倍,就可以认为是正常的,如果高于两倍的话就是变慢了。

对于redis 在虚拟化环境来说,在虚拟化环境(例如虚拟机或容器)中,由于增加了虚拟化软件层,与物理机相比,虚拟机或容器本身就会引入一定的性能开销,所以基线性能会高一些。

以上就是我们判断redis 是是否变慢了

这种方法只是考虑到了软硬件对Redis 的影响,只是在本地测试的。如果想进一步了解网络对Redis 的影响,可以用 iPerf 工具

Redis 变慢如何解决

我们先从redis 本身考虑,关注慢查询命令,所谓慢查询命令就是操作复杂度很高的命令。可以看一看官网,对每个命令复杂度都有介绍

比如 当Redis 操作的是 String时,主要操作的是hash 表,复杂度是O(1),如果操作类型为Set 时,SORT、SUNION/SMEMBERS 复杂度时 O(N+M*log(M)) 和 O(N)。其中,N 为 Set 中的元素个数,M 为 SORT 操作返回的元素个数。特别要注意set、Zset 的获取元素,交集以及并集操作。

发现Redis 性能很慢的话,可以通过Redis 日志,或者通过 latency monitor 查看慢查询的请求:

启动 Redis 延迟监控

可以在redis.conf 找到 latency-monitor-threshold 找到设置一个合适的值,这个值应该与你的基线性能的2倍,这个单位时毫秒

也可以在客户端设置

CONFIG SET latency-monitor-threshold 100

然后就可以监控,并且可以不同事件进行打印,相关的可以参考redis 官方文档。

还可以启动慢查询日志: CONFIG SET slowlog-log-slower-than 100 超过100微秒的就是慢查询,这个值可以根据测试的自己设置。

SLOWLOG GET 获取相关慢查询。

如果发现大量慢查询,解决方案如下:

  1. 有大量的慢查询,用高效的命令。如果要返回所有集合所有的元素,可以用San,避免返回大量数据

  2. 当有排序、交、并集操作,可以在客户端完成

  3. 一定不要用keys,因为需要遍历存储的键值对,所以操作延时高。

过期key的操作:

我们来看过期 key 的自动删除机制。它是 Redis 用来回收内存空间的常用机制,应用广泛,本身就会引起 Redis 操作阻塞,导致性能变慢,所以,你必须要知道该机制对性能的影响。

Redis 键值对的 key 可以设置过期时间。默认情况下,Redis 每 100 毫秒会删除一些过期 key,具体的算法如下:

  1. 采样 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 个数的 key,并将其中过期的 key 全部删除;

  2. 如果超过 25% 的 key 过期了,则重复删除的过程,直到过期 key 的比例降至 25% 以下。

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP默认值是20个key,代码里写的,默认时间是100毫秒清楚,一秒钟就清除200个,对redis 影响不大

如果触发了第二个条件,就会一直删除并释放空间,删除操作是阻塞的。redis 4.0 以后可以用异步线程删除来减少阻塞线程的影响,以前版本就会阻塞在主线程上了,这个问题解决就是 EXPIREAT 以及 EXPIREAT 的过期时间参数设置,不能让他们同时过期,应该加上一个随机值

scan的理解

关于redis 游标 (scan),在网上找了一段介绍的比较清楚的,希望对大家有帮助:

如果想要获取整个实例的所有key,建议使用SCAN命令代替。客户端通过执行SCAN $cursor COUNT $count可以得到一批key以及下一个游标$cursor,然后把这个$cursor当作SCAN的参数,再次执行,以此往复,直到返回的$cursor为0时,就把整个实例中的所有key遍历出来了。

关于SCAN讨论最多的问题就是,Redis在做Rehash时,会不会漏key或返回重复的key。 在使用SCAN命令时,不会漏key,但可能会得到重复的key,

这主要和Redis的Rehash机制有关。Redis的所有key存在一个全局的哈希表中,如果存入的key慢慢变多,在达到一定阈值后,为了避免哈希冲突导致查询效率降低,这个哈希表会进行扩容。与之对应的,key数量逐渐变少时,这个哈希表会缩容以节省空间。 1、为什么不会漏key?Redis在SCAN遍历全局哈希表时,采用高位进位法的方式遍历哈希桶(可网上查询图例,一看就明白),当哈希表扩容后,通过这种算法遍历,旧哈希表中的数据映射到新哈希表,依旧会保留原来的先后顺序,这样就可以保证遍历时不会遗漏也不会重复。 2、为什么SCAN会得到重复的key?这个情况主要发生在哈希表缩容。已经遍历过的哈希桶在缩容时,会映射到新哈希表没有遍历到的位置,所以继续遍历就会对同一个key返回多次。

SCAN是遍历整个实例的所有key,另外Redis针对Hash/Set/Sorted Set也提供了HSCAN/SSCAN/ZSCAN命令,用于遍历一个key中的所有元素,建议在获取一个bigkey的所有数据时使用,避免发生阻塞风险。

但是使用HSCAN/SSCAN/ZSCAN命令,返回的元素数量与执行SCAN逻辑可能不同。执行SCAN $cursor COUNT $count时一次最多返回count个数的key,数量不会超过count。 但Hash/Set/Sorted Set元素数量比较少时,底层会采用ziplist方式存储,如果以这种方式存储,在执行HSCAN/SSCAN/ZSCAN命令时,会无视count参数,直接把所有元素一次性返回,也就是说,得到的元素数量是会大于count参数的。当底层转为哈希表或跳表存储时,才会真正使用发count参数,最多返回count个元素。文章来源地址https://www.toymoban.com/news/detail-837471.html

到了这里,关于redis 性能优化二的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 数据库性能优化的基本方法

    一、基本方法 数据库表结构优化。优化表结构,避免过度冗余设计和数据重复。 索引优化。根据查询需求,建立合适的索引,提高查询速度。 查询语句优化。编写高效的查询语句,避免全表扫描和子查询,减少 JOIN 操作。 数据库缓存优化。使用缓存技术,将频繁访问的数据

    2024年02月15日
    浏览(64)
  • MySQL数据库性能优化技巧介绍

    MySQL是目前最流行和广泛使用的开源关系型数据库之一,随着数据量的增长和访问负载的提高,优化数据库性能变得至关重要,以确保系统能够高效地处理大量的并发请求。本文将记录一些MySQL数据库性能优化的技巧,提高数据库的运行效率,提升系统性能。 对于MySQL,最简单

    2024年02月08日
    浏览(134)
  • 【NOSQL数据库】Redis数据库的配置与优化一

    关系型数据库是一个结构化的数据库, 创建在关系模型(二维表格模型)基础上 ,一般面向于记录。 SQL 语句(标准数据查询语言)就 是一种基于关系型数据库的语言 ,用于执行对关系型数据库中数据的检索和操作。 主流的关系型数据库包括 Oracle、MySQL、SQL Server、Microso

    2024年02月11日
    浏览(50)
  • 达梦8数据库性能优化思路浅谈

        作为一名DBA,SQL优化是我们工作中必不可少的技能,在投产的系统中,存在大量的SQL语句需要我们分析和快速做出处理。很是考验我们的经验。这些慢SQL的原因有很多,有SQL编码不规范,设计有缺陷,SQL场景未考虑全面,数据量未评估等,预先需要建立索引的表而未设计建

    2024年02月06日
    浏览(46)
  • 顶级大厂Quora如何优化数据库性能?

    Quora 的流量涉及大量阅读而非写入,一直致力于优化读和数据量而非写。 读取 数据量 写入 ① 复杂查询,如连接、聚合等 在查询计数已成为问题的情况下,它们在另一个表中构建了计数,以便它们可以直接读取计数值而非计算计数。 ② 大型扫描 他们使用 LIMIT 改变它或使用

    2024年02月05日
    浏览(47)
  • MySQL数据库进行性能优化的思路

    对MySQL数据库进行性能优化的思路可以涵盖以下方面: 索引优化: 索引是提高查询性能的关键。确保表中的关键列和经常用于查询条件的列都被适当地创建了索引。可以使用 CREATE INDEX 语句添加索引,或者使用 ALTER TABLE 语句在已有表上添加索引。例如,对于一个用户表中的

    2024年02月06日
    浏览(55)
  • 数据库——MySQL高性能优化规范

    所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用 MySQL 保留(如果表名中包含查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过 32 个字符 临时库表必须以 tmp_为前缀并以日期为后缀,

    2024年02月11日
    浏览(104)
  • MySQL——性能优化与关系型数据库

    吞吐与延迟:有些结论是反直觉的,指导我们关注什么。 没有量化就没有改进:监控与度量指标,指导我们怎么去入手。 80/20原则:先优化性能瓶颈问题,指导我们如何去优化。 过早的优化是万恶之源:指导我们要选择优化的时机。 脱离场景谈性能都是耍流氓:指导我们对

    2024年02月01日
    浏览(50)
  • 数据库优化系列教程(2)—性能评估和监控

            这一步骤对于数据库优化至关重要。性能评估帮助我们深入了解当前系统的运行状况,而监控系统则确保我们能够实时了解数据库的性能变化。及时的评估和监控有助于快速识别和解决潜在问题,确保数据库系统能够稳定高效地运行。         在性能评估中,

    2024年01月16日
    浏览(62)
  • 7个工程应用中数据库性能优化经验分享

    摘要: 此篇文章分别从sql执行过程、执行计划、索引数据结构、索引查询提速原理、聚焦索引、左前缀优化原则、自增主键索引这些角度谈一谈我们对数据库优化的理解。 本文分享自华为云社区《工程应用中数据库性能优化经验小结》,作者: 叶工 。 现阶段交付的算法产

    2024年02月06日
    浏览(52)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包