Redis 的 BigKey、HotKey 又引发了线上事故！( 二 ) _Redis

2.Redis 分布式集群优势弱化：
如果请求不够均衡，过于单点，那么redis分布式集群的优势也必然被弱化。
3.可能造成资损：
在极端场景下，容易发生边界数据处理不及时，在订单等场景下，可能造成资损。
4.引发缓存击穿：
我们都知道，当缓存请求不到，就会去请求数据库。如果请求过于集中，redis承载不了，就会有大量请求打到数据库。此时，可能引发数据库服务瘫痪。进而引发系统雪崩。
5.cpu占用高，影响其他服务：
单个分片cpu占用率过高，其他分片无法拥有cpu资源，从而被影响。
三、如何发现bigkey和hotkey1.业务分析结合技术方案：通常需要对业务场景做分析，结合技术方案去判断是否会出现大key、热key的问题。
比如说：
（1）购物车场景，当一个购物车的key设计，没有上限，没有其他随机值约束，仅使用了mid 。这个时候就要注意，如果有个购物狂，一次加购5w件商品怎么办？
（2）活动资格列表场景，当一个活动的资格查询list被放入一个key，活动期间频繁的查询和操作。这个时候就要注意，list的数据量有多少？查询资格的操作是否集中？如果集中，qps是多少？
2.借助redis命令来发现：Redis4.0 及以上版本提供了--Bigkeys, --hotkeys 命令，可以分析出实例中每种数据结构的 top 1 的 Bigkey，同时给出了每种数据类型的键值个数以及平均大小。
查看bigkey：redis-cli -a 登录密码 --bigkeys
查看hotkey：redis-cli -a 登录密码 --hotkeys
--bigkey 的使用示例

文章插图

3.借助工具：(1)可使用redis可视化工具进行查看（例如：another redis desktop manager）

文章插图

可视化的工具可以明确给出redis集群当下的信息，经过简要数据分析，便可观测异常。
(2)借助市面上的开源工具（本文暂不对此深入探讨）
redis-rdb-tools（附：https://github.com/sripathikrishnan/redis-rdb-tools）
（3）借助公司的自研工具
如果 vivo内部的 DaaS（数据即服务）平台。
4.RDB 文件分析法通过 RDB 文件，分析 big key
四、如何解决bigkey和hotkey问题解决方案
bigkey的解决方案主要的方法：对 big key 进行拆分
对 big key 存储的数据（big value）进行拆分，变成value1，value2… valueN,
如果big value 是个大json 通过 mset 的方式，将这个 key 的内容打散到各个实例中，减小big key 对数据量倾斜造成的影响。关注公众号：码猿技术专栏，回复关键词：1111 获取阿里内部Java性能调优手册
如果big value 是个大list，可以拆成将list拆成。= list_1，list_2, list3, listN
其他数据类型同理
hotkey的解决方案主要的方法：使用本地缓存
在 client 端使用本地缓存，从而降低了redis集群对hot key的访问量，
但是本地缓存，带来两个问题：1、如果对可能成为 hot key 的 key 都进行本地缓存，那么本地缓存是否会过大，从而影响应用程序本身所需的缓存开销。
2、如何保证本地缓存和redis集群数据的有效期的一致性。
以上两个问题，具体看：聊聊 Redis+Caffeine 两级缓存
五、生产实例：以下是vivo团队Bigkey问题的解决方案此生产实例，非常宝贵，是珍贵的一线工业级实操案例，来源于 vivo 互联网数据库团队- Du Ting
【Redis 的 BigKey、HotKey 又引发了线上事故！】陈某仅仅是将其结构，做进一步的梳理，方便大家学习。
vivo 团队运维的Redis集群的介绍全网 Redis 集群有 2200 个以上，实例数量达到 4.5 万以上，
进行一次全网 Bigkey 检查，估计需要以年为时间单位，非常耗时。
Bigkey的来源Bigkey 一般都是由于程序设计不当、或者对于数据规模预估失策，比如以下的情况。