服务器之家:专注于服务器技术及软件下载分享
分类导航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|数据库技术|

服务器之家 - 数据库 - 数据库技术 - Redis键值设计的实践

Redis键值设计的实践

2023-07-13 12:09未知服务器之家 数据库技术

1 优雅的key结构 Redis的Key虽然可以自定义,但最好遵循下面的几个最佳实践约定: 遵循基本格式 : [业务名称]:[数据名]:[id] ,例如我们的登录业务,需要保存用户信息,其key可以设计成如下格式 这种设计的好处不仅在于可读性强

1 优雅的key结构

Redis的Key虽然可以自定义,但最好遵循下面的几个最佳实践约定:

遵循基本格式[业务名称]:[数据名]:[id],例如我们的登录业务,需要保存用户信息,其key可以设计成如下格式

Redis键值设计的实践

这种设计的好处不仅在于可读性强,还在于可以避免key的冲突问题,而且方便管理

Key的长度不超过44字节

无论是哪种数据类型, key都是string类型,string类型的底层编码包含int、embstr和raw三种。如果key中全是数字,那么就会直接以int类型去存储,而int占用的空间也是最小的,当然出于业务需求,我们不可能将key设计为一个全数字的,而如果不是纯数字,底层存储的就是SDS内容,如果小于44字节,就会使用embstr类型,embstr在内存中是一段连续的存储空间,内存占用相对raw来说较小,而当字节数大于44字节时,会转为raw模式存储,在raw模式下,内存空间不是连续的,而是采用一个指针指向了另外一段内存空间,在这段空间里存储SDS内容,这样空间不连续,访问的时候性能也就会收到影响,还有可能产生内存碎片

需要注意的是,如果你的redis版本低于4.0,那么界限是39字节而非44字节

Key中不包含一些特殊字符

2 拒绝BigKey

2.1 判断BigKey

BigKey顾名思义就是一个很大的Key,这里的大并不是指Key本身很大,而是指包括这个Key的Value在内的一整个键值对很大

BigKey通常以Key-Value的大小或者Key中成员的数量来综合判定,例如:

  • Key的Value过大:例如一个String类型的Key,它的Value为5MB
  • Key中的成员数过多:例如一个ZSET类型的Key,它的成员数量为10000个
  • Key中成员的Value过大:例如一个Hash类型的Key,它的成员数量虽然只有1000个,但这些成员的Value总大小为100 MB

那么如何判断元素的大小呢?redis中为我们提供了相应的命令,语法如下:

memory usage 键名

这条命令会返回一条数据占用内存的总大小,这个大小不仅包括Key和Value的大小,还包括数据存储时的一些元信息,因此可能你的Key与Value只占用了几十个字节,但最终的返回结果是几百个字节

但是我们一般不推荐使用memory指令,因为这个指令对CPU的占用率是很高的,实际开发中我们一般只需要衡量Value的大小或者Key中的成员数即可

例如如果我们使用的数据类型是String,就可以使用以下命令,返回的结果是Value的长度

strlen 键名

如果我们使用的数据类型是List,就可以使用以下命令,返回的结果是List中成员的个数

llen 键名

一般我们推荐,单个key的value小于10KB,集合类型的key元素数量小于1000

2.2 BigKey的危害

网络阻塞

当我们对一个BigKey发起读请求时,只需少量的QPS就可能导致带宽使用率被占满,导致Redis实例乃至所在物理机变慢,例如一个bigkey占用5M内存,只需要QPS达到20,那么1秒钟就会占100M的带宽

数据倾斜

集群环境下,由于所有插槽一开始都是均衡分配的,因此BigKey所在的Redis实例内存使用率会远超其他实例,从而无法使数据分片的内存资源达到均衡,最后不得不手动重新分配插槽,增加运维人员的负担

Redis阻塞

对元素较多的hash、list、zset等做运算会耗时较久,而且由于Redis是单线程的,在运算过程中会导致服务阻塞,无法接收其他用户请求

CPU压力

对BigKey的数据进行序列化或反序列化都会导致CPU的使用率飙升,影响Redis实例和本机其它应用

2.3 如何发现BigKey

既然我们知道了什么叫BigKey以及BigKey的危害,那么如何去快速发现Redis中所有的BigKey呢?这里为大家提供以下几种方案:

1)利用Redis本身提供的命令

利用以下命令,可以遍历分析所有key,并返回Key的整体统计信息与每种数据类型中Top1的BigKey

redis-cli -a 密码 --bigkeys

演示如下(这里我的redis没有设置密码,如果你的redis设置了密码,则需要使用 -a 密码 进行连接)

Redis键值设计的实践

2)自己手动编写程序进行扫描

我们可以通过自己编写程序,将Redis中所有的数据查询出来并一一统计长度来找出BigKey,这里不建议使用keys *来查询所有数据,因为keys * 是一次将所有的数据全部查找出来,如果数据量很大,key *一次可能要几十秒甚至几分钟,在如此长的时间内,Redis的主线程会因为执行该命令而被阻塞。

这里建议使用redis提供的scan命令,语法如下:

scan 起始位置 count 数量

scan扫描有点类似于分页查询,而被分页的对象是redis中所有的数据,scan命令调用一次只会从指定的起始位置开始返回指定数量的数据,以及此次扫描结束时光标所在的位置,下一次扫描时就需要从这个光标开始继续往下扫描

这里提供一个已经编写好的查找BigKey的测试类,大家可以参考一下

import com.heima.jedis.util.JedisConnectionFactory;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.ScanResult;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class JedisTest {
    private Jedis jedis;

    @BeforeEach
    void setUp() {
        // 1.建立连接
        // jedis = new Jedis("192.168.150.101", 6379);
        jedis = JedisConnectionFactory.getJedis();
        // 2.设置密码
        jedis.auth("123321");
        // 3.选择库
        jedis.select(0);
    }

    //设置string类型的长度上限,超过这个上限就判断为BigKey
    final static int STR_MAX_LEN = 10 * 1024;
    //设置集合类型允许的成员数量上限,超过这个上限就判断为BigKey
    final static int HASH_MAX_LEN = 500;

    @Test
    void testScan() {
        int maxLen = 0;
        long len = 0;

        String cursor = "0";
        do {
            // 扫描并获取一部分key
            ScanResult<String> result = jedis.scan(cursor);
            // 记录cursor
            cursor = result.getCursor();
            List<String> list = result.getResult();
            if (list == null || list.isEmpty()) {
                break;
            }
            // 遍历
            for (String key : list) {
                // 判断key的类型
                String type = jedis.type(key);
                switch (type) {
                    case "string":
                        len = jedis.strlen(key);
                        maxLen = STR_MAX_LEN;
                        break;
                    case "hash":
                        len = jedis.hlen(key);
                        maxLen = HASH_MAX_LEN;
                        break;
                    case "list":
                        len = jedis.llen(key);
                        maxLen = HASH_MAX_LEN;
                        break;
                    case "set":
                        len = jedis.scard(key);
                        maxLen = HASH_MAX_LEN;
                        break;
                    case "zset":
                        len = jedis.zcard(key);
                        maxLen = HASH_MAX_LEN;
                        break;
                    default:
                        break;
                }
                if (len >= maxLen) {
                    System.out.printf("Found big key : %s, type: %s, length or size: %d %n", key, type, len);
                }
            }
        } while (!cursor.equals("0"));
    }
    
    @AfterEach
    void tearDown() {
        if (jedis != null) {
            jedis.close();
        }
    }

}

3)第三方工具

利用第三方工具,这里推荐Redis-Rdb-Tools,它会针对Redis的RDB快照文件来分析内存使用情况,由于分析的是快照文件,因此不会占用Redis服务的任何性能,但是时效性相对较差

Redis-Rdb-Tools的github网址:https://github.com/sripathikrishnan/redis-rdb-tools

4)网络监控

使用自定义工具,监控进出Redis的网络数据,超出预警值时主动告警。一般阿里云搭建的云服务器就有相关监控页面:

Redis键值设计的实践

2.4 如何删除BigKey

BigKey内存占用较多,因此即便我们使用的是删除操作,删除BigKey也需要耗费很长时间,导致Redis主线程阻塞,引发一系列问题。

如果redis版本在4.0之后,我们可以通过异步删除命令unlink来删除一个BigKey,该命令会先把数据标记为已删除,然后再异步执行删除操作。

如果redis版本在4.0之前,针对集合类型,我们可以先遍历BigKey中所有的元素,先将子元素逐个删除,最后再删除BigKey。至于如何遍历,针对不同的集合类型,可以参考以下不同的命令

Redis键值设计的实践

3 恰当的数据类型

找出BigKey中,我们应该如何对BigKey进行优化呢?这里我们需要选择恰当的数据类型

3.1 存储对象

如果我们要存储一个User对象,有三种存储方式:

1)JSON字符串

将一整个对象转成Json格式进行存储

user:1{“name”: “Jack”, “age”: 21}

优点:实现简单粗暴

缺点:数据耦合,不够灵活,且需要维护JSON结构,占用内存相对较大

2)字段打散

将对象的不同属性存储到不同的key中

keyvalue
user:1:nameJack
user:1:age21

优点:可以灵活访问对象任意字段

缺点:由于每条数据都会有一些元信息需要存储,因此将一个Key分成多个Key进行存储,占用的内存会变的更大,且由于字段分散,当我们需要做统一控制时会变得很困难

3)hash(推荐)

使用hash结构来存储对象,对象的一个属性对应集合中的一个成员

user:1namejack
age21

优点:hash结构底层会使用ziplist压缩列表,空间占用小,且可以灵活访问对象的任意字段

缺点:代码编写时相对复杂

3.2 Hash优化

假如有一个hash类型的key,其中有100万对field和value,field是自增id,这个key存在什么问题?如何优化?

keyfieldvalue
someKeyid:0value0
..........
id:999999value999999

当hash的entry数量超过500时,底层会使用哈希表存储而不是ZipList,内存占用会变得比较高,虽然这个数量限制我们是可以通过以下命令进行修改的

config set hash-max-ziplist-entries 数量

但是entry数量如果实在太大了还是会导致BigKey问题,这是需要优化的,这里提供以下两种解决思路:

1)拆分为String类型(不推荐)

将Hash中的每个成员单独使用一个String类型的key进行存储

keyvalue
id:0value0
..........
id:999999value999999

这种方案是不推荐的,存在的问题如下

  • string结构底层没有太多内存优化的,且存储这些key的同时也会存储大量的元信息,虽然数据打散了,但是整体内存占用更多了
  • 如果我们想要批量获取这些数据,会变得格外麻烦

2)拆分成多个Hash类型

拆分为小的hash,将 id / 100 作为key, 将id % 100 作为field,这样每100个元素为一个Hash,这种方式相对上面两种来说内存占用会少很多,而且解决了Bigkey的问题,当然多少个元素作为一个Hash是自己定义的,这里建议数量不要超过500

keyfieldvalue
key:0id:00value0
..........
id:99value99
key:1id:00value100
..........
id:99value199
....
key:9999id:00value999900
..........
id:99value999999

延伸 · 阅读

精彩推荐