Redis进阶-Redis键值设计及BigKey问题

最新推荐文章于 2024-08-16 18:21:34 发布

小小工匠

最新推荐文章于 2024-08-16 18:21:34 发布

阅读量1.2w

点赞数 4

分类专栏：【Redis-进阶实战】文章标签： redis开发规范与性能优化

本文链接：https://blog.csdn.net/yangshangwei/article/details/104958460

版权

34 篇文章 27 订阅

订阅专栏

在这里插入图片描述

键值设计

(2)【建议】：简洁性

保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：
user:{uid}:friends:messages:{mid} 简化为 u:{uid}🇫🇷m:{mid}

我们知道，Redis 的一个字符串最大512M，一个二级数据结构（比如 hash、list、set 、zset）可以存储2^32-1 个元素，约40亿个元素。但是不是以为着我们可以任意存储元素呢？时刻牢记，在读写这个角度上，目前Redis还是单线程的。

其实不然，按照经验来说，如何定义bigKey 呢?

一般来说，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。当然了这不是绝对的，请依据场景，灵活处理。

我们来看个反例：一个hash 存储用户信息，我有100万用户，我全都放到一个key里。。。。这不管从哪个角度看，bigkey无疑。

一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几个例子：

社交类：粉丝列表，如果某些明星的粉丝数据，如果不精心设计下，一个明星的粉丝百万很少了吧，你都把这百万的粉丝数据放到一个key中存储，毫无疑问是bigkey
统计类：比如按天存储某项功能或者网站的用户集合，用户很少，倒是没多大问题，一旦用户多了起来，必是bigkey
缓存类：将数据从数据库加载出来以后序列化放到Redis里，这个方式非常常用，但有两个地方需要注意，第一，是不是有必要把所有字段都缓存；第二，有没有相关关联的数据，不要为了图方便把相关数据都存一个key下，产生bigkey。

核心思想：分治拆分

拆
big list： list1、list2、…listN
big hash：可以讲数据分段存储，比如一个大的key，假设存了1百万的用户数据，可以拆分成 200个key，每个key下面存放5000个用户数据
如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要
hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理
【推荐】：选择适合的数据类型

例如：实体类型(要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡)
反例：
```
set user:1:name tom
set user:1:age 19
set user:1:favor football
```
正例:
```
 hmset user:1 name tom age 19 favor football
```
【推荐】：控制key的生命周期，redis不是垃圾桶

建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。

对于非字符串的bigkey,比如 hash list set zset , 不要使用del 删除，请使用 hscan 、sscan、zscan方式渐进式删除。

同时要注意防止bigkey过期时间自动删除问题(例如一个100万的hash设置1小时过期，会触发del操作，造成阻塞）

导致redis阻塞

这个也很好理解：我们知道Redis 官方号称10万QPS，我们通常打不到这个值，但是大几万的QPS还是没问题的，这也就意味着 redis 的执行速度 1秒几万条，速度相当的快的。假设你有个bigKey , 操作一次耗时1秒，那Redis 单线程在这1秒钟就只能处理你这个Key, 后面堵了一堆请求。。。。并且你的应用序列化和反序列化这种大key , 也消耗CPU 。
导致网络拥塞

假设我们的交换机，千兆网络（小b），那么实际带宽 1024 / 8 = 128M . 假设你的这个key的大小 500KB，客户端并发 1000获取这个key，那么就意味着 1000 * 500KB = 500M ,那就是每秒产生500M的流量。先不说你的Redis能不能处理的过来这个并发下的bigKey，单说你的这个千兆网络，你说你这个网络I/O能扛得住吗？一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例也造成影响，其后果不堪设想。