Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. Java
  3. 正文
                           

【B站】Redis的BigKey(大key)、HotKey(热key)又引发了线上事故

2023-09-17 3167点热度 0人点赞 0条评论
本期作者

Redis的BigKey(大key)、HotKey(热key)又引发了线上事故

侯晓

哔哩哔哩高级测试开发工程师

日常生产中经常会碰到由于redis集群的不当访问,造成的线上问题。其中比较常见的是BigKey(大key)和HotKey(热key)的问题,这类问题不止会使服务的性能下降,还会影响用户正常使用功能,甚至会造成大范围的服务故障,故障有时还会发生连环效应,导致更加严重的后果。我们通过本文一起来探索,测试如何快速发现“大key”和“热key”的问题。

一、什么是BigKey、HotKey?

BigKey:俗称“大key”,是指redis在日常生产的过程中,某些key所占内存空间过大。

通俗来说,redis是key-value的存储方式,当一个key所对应的存储数值达到一定程度,就会出现大key的情况。redis里有多种数据存储结构,如String、List、Hash等,每种存储结构都有能够承载的数据限值。当一个key包含的内容接近限制,或者高于平均值,大key就产生了。

举个例子:该list存储了100MB的数据(假设该Redis实例可用内存空间仅150M,有1000个key,一个key就占用了 100M),在查找某个数据的过程中由于处理太久,导致请求阻塞(小tips:redis单线程特性)。体现在业务上就是频繁请求超时、页面404等。上述key,就是一个大key。

HotKey:俗称“热key”,一个key对应在一个redis分片上,当短时间内大量的请求打到该分片上,key被频繁访问,该key就是热key。

我们通过下图来简单了解下hotkey的访问关系:

Redis的BigKey(大key)、HotKey(热key)又引发了线上事故

当大量的请求,经过分发和计算,最终集中于同一个redis实例下的某个key时,该key由于被请求频率过高,而占用掉了大量资源。而其他分片,由于key的不合理分配导致请求量较少。整个redis集群呈现出了资源使用不均衡的现象。

举个例子:一线女明星官宣领证结婚,短时间内该女星微博账号被访问量激增(假设该账号内容被同步在缓存,账号id作为key),微博服务瘫痪(不具备任何实时参考性,仅作为虚拟的例子)。

在该场景下,上述key被大量访问,造成热key。

二、服务中的bigkey和

hotkey会导致什么问题

我们可以通过上述两种key的特性,来简单分析可能出现的几种问题。

大key,主要的问题是一个key所占空间太大,内存空间分配不均衡(小tips:redis是内存型key-value数据库)。那就可能引发以下问题:

1.数据请求大量超时:redis是单线程的,当一个key数据响应的久一点,就会造成后续请求频繁超时。如果服务容灾措施考虑得不够,会引发更大的问题。

2.侵占带宽网络拥堵:当一个key所占空间过大,多次请求就会占用较大的带宽,直接影响服务的正常运行。

3.内存溢出或处理阻塞:当一个较大的key存在时,持续新增,key所占内存会越来越大,严重时会导致内存数据溢出;当key过期需要删除时,由于数据量过大,可能发生主库较响应时间过长,主从数据同步异常(删除掉的数据,从库还在使用)。

热key,热key的问题是单点访问频率过高。那就可能引发以下问题:

1.分片服务瘫痪:上述有提到,redis集群会分很多个分片,每个分片有其要处理的数据范围。当某一个分片被频繁请求,该分片服务就可能会瘫痪。

2.Redis 分布式集群优势弱化:如1所述,如果请求不够均衡,过于单点,那么redis分布式集群的优势也必然被弱化。

3.可能造成资损:在极端场景下,容易发生边界数据处理不及时,在订单等场景下,可能造成资损。

4.引发缓存击穿:我们都知道,当缓存请求不到,就会去请求数据库。如果请求过于集中,redis承载不了,就会有大量请求打到数据库。此时,可能引发数据库服务瘫痪。

5.cpu占用高,影响其他服务:单个分片cpu占用率过高,其他分片无法拥有cpu资源,从而被影响。

三、测试过程中如何发现bigkey和hotkey

1.业务分析结合技术方案:

通常需要对业务场景做分析,结合技术方案去判断是否会出现大key、热key的问题。比如说:

(1)购物车场景,当一个购物车的key设计,没有上限,没有其他随机值约束,仅使用了mid。这个时候就要注意,如果有个购物狂,一次加购5w件商品怎么办?

(2)活动资格列表场景,当一个活动的资格查询list被放入一个key,活动期间频繁的查询和操作。这个时候就要注意,list的数据量有多少?查询资格的操作是否集中?如果集中,qps是多少?

2.借助redis命令来发现:

查看bigkey:redis-cli -a 登录密码 --bigkeys

查看hotkey:redis-cli -a 登录密码 --hotkeys

例:bigkey

Redis的BigKey(大key)、HotKey(热key)又引发了线上事故
(图片源数据来源于网络)

3.借助工具:

(1)可使用redis可视化工具进行查看(例如:another redis desktop manager)

Redis的BigKey(大key)、HotKey(热key)又引发了线上事故

可视化的工具可以明确给出redis集群当下的信息,经过简要数据分析,便可观测异常。

(2)借助市面上的开源工具(本文暂不对此深入探讨)

redis-rdb-tools(附:https://github.com/sripathikrishnan/redis-rdb-tools)

以上,是日常工作中对于发现redis缓存中bigkey和hotkey的思考,除上述工具和手段之外,还有很多公司针对业务特性自研了key检测工具,欢迎分享和交流~~

参考文档:

(1)  redis命令:Redis 命令参考 — Redis 命令参考

(2)  Github: https://github.com/sripathikrishnan/redis-rdb-tools

(3)  another redis desktop manager下载地址AnotherRedisDesktopManager 发行版 - Gitee.com

本文仅供学习!所有权归属原作者。侵删!文章来源: 哔哩哔哩技术 -一只雪茶酱 :http://mp.weixin.qq.com/s/m7qFeOia7DMYJhZD8IbFBQ

更多文章:

  1. 浅析Redis大Key
  2. 一次 Redis 事务使用不当引发的生产事故
  3. Redis为什么这么快?
  4. 一次访问Redis延时高问题排查与总结
  5. 6种限流实现,附代码![通俗易懂]
  6. 从代码到设计的性能优化指南
  7. 干货!有些bug,跨年才有机会见
  8. 2021.07.13 我们是这样崩的
  9. 手把手教你实战TDD
  10. 手把手教你落地DDD
标签: B站 Redis 线上事故 生产事故 bigkey hotkey
最后更新:2023-09-17

coder

分享干货文章,学习先进经验。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
最新 热点 推荐
最新 热点 推荐
视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构 干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议 视频笔记:什么是微服务,为什么是微服务? 视频笔记:什么是AI 智能体? 视频笔记:什么是Flink?
Elasticsearch 使用误区之六——富文本内容写入前不清洗基于 MySQL Binlog 实现可配置的异构数据同步马蜂窝消息总线——面向业务的消息服务设计视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构干货 | 论Elasticsearch数据建模的重要性你可以不用RxJava,但必须得领悟它的思想!如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具视频笔记:什么是Flink?
2.软件架构预述(译) 干货!有些bug,跨年才有机会见 Elasticsearch 使用误区之五——单次请求获取大量数据 Eureka源码剖析之七:架构&面试题【总结】 干货 | Elasticsearch基础但非常有用的功能之二:模板 实战:一次疑似内存泄漏的问题排查 Elasticsearch 中 _count 和 _stats 文档数量不一致的困惑与解决方案 定时任务原理方案综述

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (3) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (19) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2

x