强的网站建设,做外贸仿牌网站,抖音代刷网站推广快速,wordpress优化宝塔什么是 bigkey#xff1f; 简单来说#xff0c;如果一个 key 对应的 value 所占用的内存比较大#xff0c;那这个 key 就可以看作是 bigkey。具体多大才算大呢#xff1f;有一个不是特别精确的参考标准#xff1a; bigkey 是怎么产生的#xff1f;有什么危害#xff1f;…什么是 bigkey 简单来说如果一个 key 对应的 value 所占用的内存比较大那这个 key 就可以看作是 bigkey。具体多大才算大呢有一个不是特别精确的参考标准 bigkey 是怎么产生的有什么危害 bigkey 通常是由于下面这些原因产生的
程序设计不当比如直接使用 String 类型存储较大的文件对应的二进制数据。 对于业务的数据规模考虑不周到比如使用集合类型的时候没有考虑到数据量的快速增长。 未及时清理垃圾数据比如哈希中冗余了大量的无用键值对。 bigkey 除了会消耗更多的内存空间和带宽还会对性能造成比较大的影响。
在 Redis 常见阻塞原因总结[1]这篇文章中我们提到大 key 还会造成阻塞问题。具体来说主要体现在下面三个方面
客户端超时阻塞由于 Redis 执行命令是单线程处理然后在操作大 key 时会比较耗时那么就会阻塞 Redis从客户端这一视角看就是很久很久都没有响应。 网络阻塞每次获取大 key 产生的网络流量较大如果一个 key 的大小是 1 MB每秒访问量为 1000那么每秒会产生 1000MB 的流量这对于普通千兆网卡的服务器来说是灾难性的。 工作线程阻塞如果使用 del 删除大 key 时会阻塞工作线程这样就没办法处理后续的命令。 大 key 造成的阻塞问题还会进一步影响到主从同步和集群扩容。
综上大 key 带来的潜在问题是非常多的我们应该尽量避免 Redis 中存在 bigkey。
如何发现 bigkey 1、使用 Redis 自带的 --bigkeys 参数来查找。
# redis-cli -p 6379 --bigkeys# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).[00.00%] Biggest string found so far ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20 with 4437 bytes
[00.00%] Biggest list found so far my-list with 17 items-------- summary -------Sampled 5 keys in the keyspace!
Total key length in bytes is 264 (avg len 52.80)Biggest list found my-list has 17 items
Biggest string found ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20 has 4437 bytes1 lists with 17 items (20.00% of keys, avg size 17.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
4 strings with 4831 bytes (80.00% of keys, avg size 1207.75)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00从这个命令的运行结果我们可以看出这个命令会扫描(Scan) Redis 中的所有 key 会对 Redis 的性能有一点影响。并且这种方式只能找出每种数据结构 top 1 bigkey占用内存最大的 String 数据类型包含元素最多的复合数据类型。然而一个 key 的元素多并不代表占用内存也多需要我们根据具体的业务情况来进一步判断。
在线上执行该命令时为了降低对 Redis 的影响需要指定 -i 参数控制扫描的频率。redis-cli -p 6379 --bigkeys -i 3 表示扫描过程中每次扫描后休息的时间间隔为 3 秒。
2、使用 Redis 自带的 SCAN 命令
SCAN 命令可以按照一定的模式和数量返回匹配的 key。获取了 key 之后可以利用 STRLEN、HLEN、LLEN等命令返回其长度或成员数量。 对于集合类型还可以使用 MEMORY USAGE 命令Redis 4.0这个命令会返回键值对占用的内存空间。
3、借助开源工具分析 RDB 文件。
通过分析 RDB 文件来找出 big key。这种方案的前提是你的 Redis 采用的是 RDB 持久化。
网上有现成的代码/工具可以直接拿来使用
redis-rdb-tools[2]Python 语言写的用来分析 Redis 的 RDB 快照文件用的工具 rdb_bigkeys[3] : Go 语言写的用来分析 Redis 的 RDB 快照文件用的工具性能更好。 4、借助公有云的 Redis 分析服务。
如果你用的是公有云的 Redis 服务的话可以看看其是否提供了 key 分析功能一般都提供了。
这里以阿里云 Redis 为例说明它支持 bigkey 实时分析、发现文档地址https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature 。 如何处理 bigkey bigkey 的常见处理以及优化办法如下这些方法可以配合起来使用
分割 bigkey将一个 bigkey 分割为多个小 key。例如将一个含有上万字段数量的 Hash 按照一定策略比如二次哈希拆分为多个 Hash。 手动清理Redis 4.0 可以使用 UNLINK 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 SCAN 命令结合 DEL 命令来分批次删除。 采用合适的数据结构例如文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息0/1。 开启 lazy-free惰性删除/延迟释放 lazy-free 特性是 Redis 4.0 开始引入的指的是让 Redis 采用异步方式延迟释放 key 使用的内存将该操作交给单独的子线程处理避免阻塞主线程。
什么是 hotkey 如果一个 key 的访问次数比较多且明显多于其他 key 的话那这个 key 就可以看作是 hotkey热 Key。例如在 Redis 实例的每秒处理请求达到 5000 次而其中某个 key 的每秒访问量就高达 2000 次那这个 key 就可以看作是 hotkey。
hotkey 出现的原因主要是某个热点数据访问量暴增如重大的热搜事件、参与秒杀的商品。
hotkey 有什么危害 处理 hotkey 会占用大量的 CPU 和带宽可能会影响 Redis 实例对其他请求的正常处理。此外如果突然访问 hotkey 的请求超出了 Redis 的处理能力Redis 就会直接宕机。这种情况下大量请求将落到后面的数据库上可能会导致数据库崩溃。
因此hotkey 很可能成为系统性能的瓶颈点需要单独对其进行优化以确保系统的高可用性和稳定性。
如何发现 hotkey 1、使用 Redis 自带的 --hotkeys 参数来查找。
Redis 4.0.3 版本中新增了 hotkeys 参数该参数能够返回所有 key 的被访问次数。
使用该方案的前提条件是 Redis Server 的 maxmemory-policy 参数设置为 LFU 算法不然就会出现如下所示的错误。
# redis-cli -p 6379 --hotkeys# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).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.Redis 中有两种 LFU 算法
volatile-lfuleast frequently used从已设置过期时间的数据集server.db[i].expires中挑选最不经常使用的数据淘汰。 allkeys-lfuleast frequently used当内存不足以容纳新写入数据时在键空间中移除最不经常使用的 key。 以下是配置文件 redis.conf 中的示例
# 使用 volatile-lfu 策略
maxmemory-policy volatile-lfu# 或者使用 allkeys-lfu 策略
maxmemory-policy allkeys-lfu需要注意的是hotkeys 参数命令也会增加 Redis 实例的 CPU 和内存消耗全局扫描因此需要谨慎使用。
2、使用MONITOR 命令。
MONITOR 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式可以用于临时监控 Redis 实例的操作情况包括读写、删除等操作。
由于该命令对 Redis 性能的影响比较大因此禁止长时间开启 MONITOR生产环境中建议谨慎使用该命令。
# redis-cli
127.0.0.1:6379 MONITOR
OK
1683638260.637378 [0 172.17.0.1:61516] ping
1683638267.144236 [0 172.17.0.1:61518] smembers mySet
1683638268.941863 [0 172.17.0.1:61518] smembers mySet
1683638269.551671 [0 172.17.0.1:61518] smembers mySet
1683638270.646256 [0 172.17.0.1:61516] ping
1683638270.849551 [0 172.17.0.1:61518] smembers mySet
1683638271.926945 [0 172.17.0.1:61518] smembers mySet
1683638274.276599 [0 172.17.0.1:61518] smembers mySet2
1683638276.327234 [0 172.17.0.1:61518] smembers mySet在发生紧急情况时我们可以选择在合适的时机短暂执行 MONITOR 命令并将输出重定向至文件在关闭 MONITOR 命令后通过对文件中请求进行归类分析即可找出这段时间中的 hotkey。
3、借助开源项目。
京东零售的 hotkey 这个项目不光支持 hotkey 的发现还支持 hotkey 的处理 4、根据业务情况提前预估。
可以根据业务情况来预估一些 hotkey比如参与秒杀活动的商品数据等。不过我们无法预估所有 hotkey 的出现比如突发的热点新闻事件等。
5、业务代码中记录分析。
在业务代码中添加相应的逻辑对 key 的访问情况进行记录分析。不过这种方式会让业务代码的复杂性增加一般也不会采用。
6、借助公有云的 Redis 分析服务。
如果你用的是公有云的 Redis 服务的话可以看看其是否提供了 key 分析功能一般都提供了。
这里以阿里云 Redis 为例说明它支持 hotkey 实时分析、发现文档地址https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature 。 如何解决 hotkey hotkey 的常见处理以及优化办法如下这些方法可以配合起来使用
读写分离主节点处理写请求从节点处理读请求。 使用 Redis Cluster将热点数据分散存储在多个 Redis 节点上。 二级缓存hotkey 采用二级缓存的方式进行处理将 hotkey 存放一份到 JVM 本地内存中可以用 Caffeine。 除了这些方法之外如果你使用的公有云的 Redis 服务话还可以留意其提供的开箱即用的解决方案。
这里以阿里云 Redis 为例说明它支持通过代理查询缓存功能Proxy Query Cache优化热点 Key 问题。
