常用的 Redis 优化手段有哪些?

2021-01-20  本文已影响0人  you的日常

每个软件的常规操作有两种,一种是使用,另一种就是调优,对于 Redis 来说也是一样。关于 Redis 调优的问题一般会出现在 Redis 面试的后期,以此来考察面试者对于 Redis 的实际应用掌握,以及对于 Redis 高性能的追求与理解,因此本文就来重点的聊一聊关于 Redis 调优的相关问题。

我们本文的面试题是,Redis 常见的优化手段有哪些?

典型回答

最有效的提高 Redis 性能的方案就是在没有必要开启持久化的情况下,关闭 Redis 的持久化功能,这样每次对 Redis 的操作就无需进行 IO 磁盘写入了,因此性能会提升很多。

其他优化 Redis 的常见手段有,缩短键值对的存储长度和不使用耗时长的 Redis 命令。

缩短键值对的存储长度

键值对的长度是和性能成反比的,比如我们来做一组写入数据的性能测试,执行结果如下:

| 数据量 | key 大小 | value 大小 | string:set 平均耗时 | hash:hset 平均耗时 | | :--- | :--- | :--- | :--- | :--- | | 100w | 20byte | 512byte | 1.13 微秒 | 10.28 微秒 | | 100w | 20byte | 200byte | 0.74 微秒 | 8.08 微秒 | | 100w | 20byte | 100byte | 0.65 微秒 | 7.92 微秒 | | 100w | 20byte | 50byte | 0.59 微秒 | 6.74 微秒 | | 100w | 20byte | 20byte | 0.55 微秒 | 6.60 微秒 | | 100w | 20byte | 5byte | 0.53 微秒 | 6.53 微秒 |

从以上数据可以看出,在 key 不变的情况下,value 值越大操作效率越慢,因为 Redis 对于同一种数据类型会使用不同的内部编码进行存储,比如字符串的内部编码就有三种:int(整数编码)、raw(优化内存分配的字符串编码)、embstr(动态字符串编码),这是因为 Redis 的作者是想通过不同编码实现效率和空间的平衡,然而数据量越大使用的内部编码就越复杂,而越是复杂的内部编码存储的性能就越低。

这还只是写入时的速度,当键值对内容较大时,还会带来另外几个问题:

因此在保证完整语义的同时,我们要尽量的缩短键值对的存储长度,必要时要对数据进行序列化和压缩再存储,以 Java 为例,序列化我们可以使用 protostuff 或 kryo,压缩我们可以使用 snappy。

禁止使用耗时长的 Redis 命令

Redis 绝大多数读写命令的时间复杂度都在 O(1) 到 O(N) 之间,在官方文档对每个命令都有时间复杂度说明,地址:https://redis.io/commands,如下图所示:

image.png

其中 O(1) 表示可以安全使用的,而 O(N) 就应该当心了,N 表示不确定,数据越大查询的速度可能会越慢。因为 Redis 只用一个线程来做数据查询,如果这些指令耗时很长,就会阻塞 Redis,造成大量延时。

要避免 O(N) 命令对 Redis 造成的影响,可以从以下几个方面入手改造:

考点分析

Redis 优化的手段有很多,老子教育我们“天下难事必作于易,天下大事必作于细”,我们只有将每个 Redis 优化的细节都做到位,才能打造一个性能优秀的 Redis 服务,才能在茫茫面试的人群中脱颖而出,高手过招通常看得都是细节,上面大概回答了本文的面试题,也属于卓有成效的几种方法,但如果能回答出更多优化的技巧的话,相信一定能让面试官惊喜万分,给他眼前一亮的感觉。

和此知识点相关的面试题还有以下这些:

知识扩展

1.Redis 管道技术——Pipeline

管道技术 (Pipeline) 是客户端提供的一种批处理技术,用于一次处理多个 Redis 命令,从而提高整个交互的性能。也就是说 Pipeline 并不是 Redis 服务器的功能,而是客户端提供的批量处理 Redis 命令的功能。

通常情况下 Redis 是单行执行的,客户端先向服务器发送请求,服务端接收并处理请求后再把结果返回给客户端,这种处理模式在非频繁请求时不会有任何问题,但如果出现集中大批量的请求时,因为每个请求都要经历先请求再响应的过程,这就会造成网络资源浪费,此时就需要管道技术来把所有的命令整合一次发给服务端,再一次响应给客户端,这样就能大大的提升了 Redis 的响应速度。

普通命令模式,如下图所示: 普通模式.png
上一篇下一篇

猜你喜欢

热点阅读