@@ -186,6 +186,11 @@ Redis 从 2.6 版本开始支持执行 Lua 脚本,它的功能和事务非常
186186
187187## Redis 性能优化(重要)
188188
189+ 除了下面介绍的内容之外,再推荐两篇不错的文章:
190+
191+ - [ 你的 Redis 真的变慢了吗?性能优化如何做 - 阿里开发者] ( https://mp.weixin.qq.com/s/nNEuYw0NlYGhuKKKKoWfcQ )
192+ - [ Redis 常见阻塞原因总结 - JavaGuide] ( ./redis-common-blocking-problems-summary.md )
193+
189194### 使用批量操作减少网络传输
190195
191196一个 Redis 命令的执行可以简化为以下 4 步:
@@ -271,15 +276,15 @@ Lua 脚本同样支持批量操作多条命令。一段 Lua 脚本可以视作
271276
272277个人建议不管是否开启 lazy-free,我们都尽量给 key 设置随机过期时间。
273278
274- ### Redis bigkey
279+ ### Redis bigkey(大 Key)
275280
276281#### 什么是 bigkey?
277282
278283简单来说,如果一个 key 对应的 value 所占用的内存比较大,那这个 key 就可以看作是 bigkey。具体多大才算大呢?有一个不是特别精确的参考标准:string 类型的 value 超过 10 kb,复合类型的 value 包含的元素超过 5000 个(对于复合类型的 value 来说,不一定包含的元素越多,占用的内存就越多)。
279284
280285#### bigkey 有什么危害?
281286
282- 除了会消耗更多的内存空间, bigkey 对性能也会有比较大的影响 。因此,我们应该尽量避免写入 bigkey!
287+ bigkey 除了会消耗更多的内存空间和带宽,还会对性能造成比较大的影响 。因此,我们应该尽量避免 Redis 中存在 bigkey。
283288
284289#### 如何发现 bigkey?
285290
@@ -313,7 +318,7 @@ Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28
313318
314319从这个命令的运行结果,我们可以看出:这个命令会扫描(Scan) Redis 中的所有 key ,会对 Redis 的性能有一点影响。并且,这种方式只能找出每种数据结构 top 1 bigkey(占用内存最大的 string 数据类型,包含元素最多的复合数据类型)。
315320
316- ** 2、分析 RDB 文件**
321+ ** 2、借助开源工具分析 RDB 文件。 **
317322
318323通过分析 RDB 文件来找出 big key。这种方案的前提是你的 Redis 采用的是 RDB 持久化。
319324
@@ -322,6 +327,130 @@ Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28
322327- [redis-rdb-tools](https://github.com/sripathikrishnan/redis-rdb-tools):Python 语言写的用来分析 Redis 的 RDB 快照文件用的工具
323328- [rdb_bigkeys](https://github.com/weiyanwei412/rdb_bigkeys) : Go 语言写的用来分析 Redis 的 RDB 快照文件用的工具,性能更好。
324329
330+ ** 3、借助公有云的 Redis 分析服务。**
331+
332+ 如果你用的是公有云的 Redis 服务的话,可以看看其是否提供了 key 分析功能(一般都提供了)。
333+
334+ 这里以阿里云 Redis 为例说明,它支持 bigkey 实时分析、发现,文档地址:< https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature> 。
335+
336+ ! [阿里云Key分析](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-key-analysis.png)
337+
338+ # ### 如何处理 bigkey?
339+
340+ bigkey 的常见处理以及优化办法如下(这些方法可以配合起来使用):
341+
342+ - ** 分割 bigkey** :将一个 bigkey 分割为多个小 key。这种方式需要修改业务层的代码,一般不推荐这样做。
343+ - ** 手动清理** :Redis 4.0+ 可以使用 ` UNLINK` 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 ` SCAN` 命令结合 ` DEL` 命令来分批次删除。
344+ - ** 采用合适的数据结构** :比如使用 HyperLogLog 统计页面 UV。
345+
346+ # ## Redis hotkey(热 Key)
347+
348+ # ### 什么是 hotkey?
349+
350+ 简单来说,如果一个 key 的访问次数比较多且明显多于其他 key 的话,那这个 key 就可以看作是 hotkey。例如在 Redis 实例的每秒处理请求达到 5000 次,而其中某个 key 的每秒访问量就高达 2000 次,那这个 key 就可以看作是 hotkey。
351+
352+ hotkey 出现的原因主要是某个热点数据访问量暴增,如重大的热搜事件、参与秒杀的商品。
353+
354+ # ### hotkey 有什么危害?
355+
356+ 处理 hotkey 会占用大量的 CPU 和带宽,可能会影响 Redis 实例对其他请求的正常处理。此外,如果突然访问 hotkey 的请求超出了 Redis 的处理能力,Redis 就会直接宕机。这种情况下,大量请求将落到后面的数据库上,可能会导致数据库崩溃。
357+
358+ 因此,hotkey 很可能成为系统性能的瓶颈点,需要单独对其进行优化,以确保系统的高可用性和稳定性。
359+
360+ # ### 如何发现 hotkey?
361+
362+ ** 1、使用 Redis 自带的 ` --hotkeys` 参数来查找。**
363+
364+ Redis 4.0.3 版本中新增了 ` hotkeys` 参数,该参数能够返回所有 key 的被访问次数。
365+
366+ 使用该方案的前提条件是 Redis Server 的 ` maxmemory-policy` 参数设置为 LFU 算法,不然就会出现如下所示的错误。
367+
368+ ` ` ` bash
369+ # redis-cli -p 6379 --hotkeys
370+
371+ # Scanning the entire keyspace to find hot keys as well as
372+ # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
373+ # per 100 SCAN commands (not usually needed).
374+
375+ Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.
376+ ` ` `
377+
378+ Redis 中有两种 LFU 算法:
379+
380+ - ** volatile-lru(least recently used)** :从已设置过期时间的数据集(` server.db[i].expires` )中挑选最近最少使用的数据淘汰。
381+ - ** allkeys-lru(least recently used)** :当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 key(这个是最常用的)。
382+
383+ 以下是配置文件 ` redis.conf` 中的示例:
384+
385+ ` ` ` properties
386+ # 使用 volatile-lfu 策略
387+ maxmemory-policy volatile-lfu
388+
389+ # 或者使用 allkeys-lfu 策略
390+ maxmemory-policy allkeys-lfu
391+ ` ` `
392+
393+ 需要注意的是,` hotkeys` 命令也会增加 Redis 实例的 CPU 和内存消耗(全局扫描),因此需要谨慎使用。
394+
395+ ** 2、使用` monitor` 命令。**
396+
397+ ` monitor` 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式,可以用于临时监控 Redis 实例的操作情况,包括读写、删除等操作。
398+
399+ 由于该命令对 Redis 性能的影响比较大,因此禁止长时间开启 ` monitor` (生产环境中建议谨慎使用该命令)。
400+
401+ ` ` ` java
402+ # redis-cli
403+ 127.0.0.1:6379> monitor
404+ OK
405+ 1683638260.637378 [0 172.17.0.1:61516] " ping"
406+ 1683638267.144236 [0 172.17.0.1:61518] " smembers" " mySet"
407+ 1683638268.941863 [0 172.17.0.1:61518] " smembers" " mySet"
408+ 1683638269.551671 [0 172.17.0.1:61518] " smembers" " mySet"
409+ 1683638270.646256 [0 172.17.0.1:61516] " ping"
410+ 1683638270.849551 [0 172.17.0.1:61518] " smembers" " mySet"
411+ 1683638271.926945 [0 172.17.0.1:61518] " smembers" " mySet"
412+ 1683638274.276599 [0 172.17.0.1:61518] " smembers" " mySet2"
413+ 1683638276.327234 [0 172.17.0.1:61518] " smembers" " mySet"
414+ ` ` `
415+
416+ 在发生紧急情况时,我们可以选择在合适的时机短暂执行 monitor 命令并将输出重定向至文件,在关闭 monitor 命令后通过对文件中请求进行归类分析即可找出这段时间中的 hotkey。
417+
418+ ** 3、借助开源项目。**
419+
420+ 京东零售的 [hotkey](https://gitee.com/jd-platform-opensource/hotkey) 这个项目不光支持 hotkey 的发现,还支持 hotkey 的处理。
421+
422+ ! [京东零售开源的 hotkey](https://oss.javaguide.cn/github/javaguide/database/redis/jd-hotkey.png)
423+
424+ ** 4、根据业务情况提前预估。**
425+
426+ 可以根据业务情况来预估一些 hotkey,比如参与秒杀活动的商品数据等。不过,我们无法预估所有 hotkey 的出现,比如突发的热点新闻事件等。
427+
428+ ** 5、业务代码中记录分析。**
429+
430+ 在业务代码中添加相应的逻辑对 key 的访问情况进行记录分析。不过,这种方式会让业务代码的复杂性增加,一般也不会采用。
431+
432+ ** 6、借助公有云的 Redis 分析服务。**
433+
434+ 如果你用的是公有云的 Redis 服务的话,可以看看其是否提供了 key 分析功能(一般都提供了)。
435+
436+ 这里以阿里云 Redis 为例说明,它支持 hotkey 实时分析、发现,文档地址:< https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature> 。
437+
438+ ! [阿里云Key分析](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-key-analysis.png)
439+
440+ # ### 如何解决 hotkey?
441+
442+ hotkey 的常见处理以及优化办法如下(这些方法可以配合起来使用):
443+
444+ - ** 读写分离** :主节点处理写请求,从节点处理读请求。
445+ - ** 使用 Redis Cluster** :将热点数据分散存储在多个 Redis 节点上。
446+ - ** 二级缓存** :hotkey 采用二级缓存的方式进行处理,将 hotkey 存放一份到 JVM 本地内存中(可以用 Caffeine)。
447+
448+ 除了这些方法之外,如果你使用的公有云的 Redis 服务话,还可以留意其提供的开箱即用的解决方案。
449+
450+ 这里以阿里云 Redis 为例说明,它支持通过代理查询缓存功能(Proxy Query Cache)优化热点 Key 问题。
451+
452+ ! [通过阿里云的Proxy Query Cache优化热点Key问题](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-hotkey-proxy-query-cache.png)
453+
325454# ## Redis 内存碎片
326455
327456** 相关问题** :
@@ -518,5 +647,6 @@ Cache Aside Pattern 中遇到写请求是这样的:更新 DB,然后直接删
518647
519648- 《Redis 开发与运维》
520649- 《Redis 设计与实现》
521- - Redis Transactions : https://redis.io/docs/manual/transactions/
522- - What is Redis Pipeline:https://buildatscale.tech/what-is-redis-pipeline/
650+ - Redis Transactions : < https://redis.io/docs/manual/transactions/>
651+ - What is Redis Pipeline:< https://buildatscale.tech/what-is-redis-pipeline/>
652+ - 一文详解 Redis 中 BigKey、HotKey 的发现与处理:< https://mp.weixin.qq.com/s/FPYE1B839_8Yk1-YSiW-1Q>
0 commit comments