当前位置: 首页 > article >正文

Redis--20--大Key问题解析

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档

文章目录

  • 大Key问题
    • 1.什么是 Redis 大 Key?
        • 在 Redis 中,大 Key 是指==单个键值对==的数据量非常大,可能包含大量数据。
    • 2. Redis大Key的危害
    • 3.大key、热key的产生原因:
    • 4.为什么需要关注大Key问题?
  • Redis大Key引发的线上事故场景
    • 1. 常见事故场景描述
      • 1.1 **操作大Key导致Redis阻塞**
      • 1.2 大Key迁移时的性能问题
      • 1.3 慢查询和超时的影响
    • 2. 事故表现及影响
      • 2.1 业务卡顿
      • 2.2 系统不可用
      • 2.3 难以快速恢复


大Key问题

大Key并不直接导致系统问题,但其潜在影响和风险非常显著,尤其在生产环境中。
在这里插入图片描述

1.什么是 Redis 大 Key?

在 Redis 中,大 Key 是指单个键值对的数据量非常大,可能包含大量数据。

Redis大Key是指单个Key对应的数据量过大,占用过多的内存或导致操作耗时较长的现象。大Key可以是以下几种常见数据类型中的任意一种:

  • String类型:单个字符串的长度过大。
  • List类型:包含大量元素的列表。
  • Hash类型:存储大量字段的哈希表。
  • Set或ZSet类型:存储大量成员的集合或有序集合。

数值参考
在这里插入图片描述

2. Redis大Key的危害

  • 性能瓶颈:对大Key的读写操作可能占用过多的CPU资源,导致其他操作延迟。

  • 阻塞问题:一次性删除大Key或迁移大Key时,Redis可能出现阻塞,从而影响整个服务。

  • 内存压力:大Key会占用大量内存,增加内存碎片化的风险,并可能触发Redis的内存淘汰机制。

  • 恢复缓慢:当需要从快照(RDB)或日志(AOF)中加载数据时,大Key会显著延长恢复时间。

具体

  1. 对Redis的请求变慢。
  2. Redis内存不断变大引发OOM,或达到maxmemory值引发写阻塞或重要Key被逐出。
  3. Redis Cluster中的某个node内存远超其余node。
  4. 由于对大key的请求很慢,容易造成请求的阻塞,在分布式架构下容易造成服务雪崩。
  5. 删除一个大Key很耗时,容易造成主结点阻塞,从而主从切换。

3.大key、热key的产生原因:

  • 存放不合理,存储了不适合存放在内存中的数据,如用key存放音频视频这一类大体积二进制文件(大key)。
  • 设计不合理,造成个别key中成员过多。(大key)。
  • 未定期清理数据,没有设置过期时间,造成了如hash类型中key中的成员不断增加。
  • 流量陡增,如出现某款爆款商品等(热key)。
  • bug,代码的业务逻辑上对key的成员只增不减也未设置过期时间。

4.为什么需要关注大Key问题?

在生产环境中,Redis被广泛用作缓存和数据库,如果忽略大Key问题,可能导致以下后果:

  1. 线上事故频发:由于Redis本身是单线程模型,大Key的操作会阻塞主线程,影响所有客户端请求。
  2. 业务中断:高延迟甚至不可用的情况会对业务造成直接损失。
  3. 运维复杂度增加:需要额外的监控和排查,增加了运维负担。

Redis大Key引发的线上事故场景

1. 常见事故场景描述

1.1 操作大Key导致Redis阻塞

  • Redis是单线程执行命令的,在操作大Key(如读取、更新或删除)时,单次命令可能需要较长时间完成,阻塞其他客户端请求。
  • 例如:使用DEL删除一个包含数百万元素的List或Set时,操作可能耗时几秒甚至更久,导致其他请求无法响应。

1.2 大Key迁移时的性能问题

  • 在Redis进行主从同步或数据迁移时,大Key的传输会占用大量带宽和时间。
    如果迁移操作与正常业务请求同时进行,可能导致Redis服务性能大幅下降,甚至引发业务中断。

1.3 慢查询和超时的影响

  • 对大Key执行复杂操作(如LRANGE、HGETALL、ZRANGEBYSCORE)时,操作时间会随着数据量的增长线性甚至指数级增加,可能触发慢查询或请求超时。
  • 例如:一次性从一个包含百万条数据的List中获取范围数据,容易导致应用程序响应缓慢。

2. 事故表现及影响

2.1 业务卡顿

  • 用户请求无法及时得到响应,表现为接口延迟增加甚至超时。
  • 对于高并发场景,这种情况会进一步放大,导致更多请求堆积。

2.2 系统不可用

  • 阻塞问题可能让整个Redis实例无法响应请求,导致相关业务完全瘫痪。
  • 如果Redis作为缓存使用,缓存不可用会给后端数据库带来极大压力,可能进一步引发数据库瓶颈。

2.3 难以快速恢复

  • 在线上恢复过程中,删除或迁移大Key会进一步延长恢复时间。
  • 大Key也会导致Redis内存碎片增加,可能需要触发MEMORY FRAGMENTATION的手动优化,进一步增加停机时间。

http://www.kler.cn/a/473117.html

相关文章:

  • spring mvc源码学习笔记之九
  • 33.3K 的Freqtrade:开启加密货币自动化交易之旅
  • 课题推荐——基于GPS的无人机自主着陆系统设计
  • 基于Python的投资组合收益率与波动率的数据分析
  • HackMyVM-Again靶机的测试报告
  • 虚表 —— 隐藏行(简单版)
  • Mono里运行C#脚本26—CEE_ADD/MONO_CEE_ADD/OP_IADD/X86_ADD的转换过程
  • java项目学科竞赛管理系统的设计与实现源码(springboot+mysql+vue)
  • 预训练语言模型——BERT
  • 【免费】2000-2019年各省技术市场成交额数据
  • 字玩FontPlayer开发笔记9 Tauri2打包应用
  • Golang的并发编程框架比较
  • ASP.NET Core实现微服务--什么是微服务
  • Java语法总结
  • 【Uniapp-Vue3】computed计算属性用法及方法对比
  • Scratch024(糖饼印花)
  • 数据分析思维(九):分析方法——AARRR模型分析方法
  • docker minio镜像arm64架构
  • Ruby语言的软件开发工具
  • 精选2款.NET开源的博客系统
  • 表达式翻译 一
  • Agentic AI 深度剖析
  • Spark创建多种数据格式的DataFrame
  • 消息队列:原理、问题与设计全解析
  • BERT模型详解及代码复现
  • JAVA学习记录3