Redis从入门到精通(二十)Redis最佳实践(一)优雅的Key结构、拒绝BigKey

文章目录

第7章 Redis最佳实践
- 7.1 Redis键值设计
- - 7.1.1 优雅的Key结构
  - 7.1.2 拒绝BigKey
  - - 7.1.2.1 何为BigKey
    - 7.1.2.2 BigKey的危害
    - 7.1.2.3 如何发现BigKey
    - 7.1.2.4 如何删除BigKey
  - 7.1.3 恰当的数据类型
  - - 7.1.3.1 存储Java对象
    - 7.1.3.2 存储hash数据
  - 7.1.4 小结

第7章 Redis最佳实践

7.1 Redis键值设计

7.1.1 优雅的Key结构

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

遵循基本格式：[业务名称]:[数据名]:[id]
长度不超过44字节
不包含特殊字符

例如，保存登录用户信息可以这样设计：login:user:1。

这样设计的好处在于：可读性强；可避免Key冲突；方便管理；更节省空间。

Key是string类型的，其底层编码包含int、embstr和raw三种。其中，embstr在小于44字节使用，采用连续内存空间，内存占用更小。而当字节数大于44字节时，会转为raw模式存储，在raw模式下内存空间不是连续的，而是采用一个指针指向了另外一段内存空间，访问的时候性能也就会受到影响，还有可能产生内存碎片。如图：

7.1.2 拒绝BigKey

7.1.2.1 何为BigKey

BigKey通常以Key本身的大小和Key中成员的数量来综合判定，例如：

Key本身的数据量过大：一个string类型的Key，它的值为5MB；
Key中成员的数量过多：一个zset类型的Key，它的成员数量为10000个；
Key中成员的数据量过大：一个hash类型的Key，它的成员数量虽然只有1000个,但这些成员的Value值总大小为100MB。

Redis提供了 memory usage 命令来查看指定Key及其Value的大小：

127.0.0.1:6379> set name Jack
OK
127.0.0.1:6379> memory usage name
(integer) 56
127.0.0.1:6379> set name aaaaaaaaaaaaaa
OK
127.0.0.1:6379> memory usage name
(integer) 72

但一般不推荐使用memory命令，因为这个指令对CPU的使用率是比较高的。 在实际开发中，一般只需要衡量值的长度就可以了：

127.0.0.1:6379> strlen name
(integer) 14
127.0.0.1:6379> lpush l2 s1 s2
(integer) 2
127.0.0.1:6379> llen l2
(integer) 2

通常情况下，建议单个Key的Value值小于10KB；而对于集合类型的Key，建议元素数量小于1000个。

7.1.2.2 BigKey的危害

网络阻塞：对BigKey执行读请求时，少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢；
数据倾斜：BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡；
Redis阻塞：对元素较多的hash、list、zset等做运算会耗时较久，使主线程被阻塞；
CPU压力：对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用。

7.1.2.3 如何发现BigKey

1）redis-cli --bigkeys

利用redis-cli --bigkeys命令，可以遍历分析所有Key，并返回Key的整体统计信息与每种数据类型的Top1的BigKey：

2）scan扫描

自己编程，利用scan扫描Redis中的所有Key，利用strlen、hlen等命令判断Key的长度：

// 自定义string类型，超过400KB，则是BigKey
final static int STR_MAX_LEN = 400;
// 自定义hash类型，超过100KB，则是BigKey
final static int HASH_MAX_LEN = 100;@Test
public void testScan() {int maxLen = 0;long len = 0;int cursor = 0;do {// 扫描并获取一部分KeyScanResult<String> result = jedis.scan(cursor);// 记录此时的cursorcursor = result.getCursor();List<String> list = result.getResult();if (list == null || list.isEmpty()) {break;}// 遍历这一部分Keyfor (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;}// 如果查询出来的长度超过自定义的长度，则是BigKeyif (len >= maxLen) {System.out.printf("Found big key : %s, type: %s, length or size: %d %n", key, type, len);}}} while (cursor != 0);
}

执行以上单元测试结果如下：

Found big key : item:id:1, type: string, length or size: 411 
Found big key : item:id:5, type: string, length or size: 406 
Found big key : item:id:4, type: string, length or size: 440 
Found big key : item:id:3, type: string, length or size: 432

3）第三方工具

利用第三方工具，如Redis-Rdb-Tools分析RDB快照文件，全面分析内存使用情况。详见：https://github.com/sripathikrishnan/redis-rdb-tools

4）网络监控

自定义工具，监控进出Redis的网络数据，超出预警值时主动告警。

7.1.2.4 如何删除BigKey

BigKey内存占用较多，删除这样的Key也需要耗费很长时间，从而导致Redis主线程阻塞，引发一系列问题。

为此，Redis在4.0后提供了异步删除的命令：UNLINK key [key ...]。

7.1.3 恰当的数据类型

7.1.3.1 存储Java对象

比如要存储一个User对象，一般有三种存储方式：

1）JSON字符串

{"name":"Jack","age":21}

优点：实现简单粗暴
缺点：数据耦合，不够灵活

2）字段打散

login:user:1:name	Jack
login:user:1:name	21

优点：可以灵活访问对象任意字段
缺点：占用空间大、没办法做统一控制

3）hash（推荐）

login:user:1	name	Jack
login:user:1	age	21

优点：底层使用ziplist，空间占用小，可以灵活访问对象的任意字段
缺点：代码相对复杂

7.1.3.2 存储hash数据

假设有一个hash类型的Key，其有10万对field和value，field是自增id，那这个Key存在什么问题？如何优化？

key	id:0	value0
	......	......
	id:99999	value99999

1）存在的问题

hash的entry数量超过500时，会使用哈希表而不是ZipList，内存占用较多。Redis支持通过 hash-max-ziplist-entries 配置entry上限，但是如果entry过多就会导致BigKey问题。

这里可以编写一个单元测试，往Redis存入100000条数据：

@Test
public void testHashMemory() {for (int i = 0; i < 100000; i++) {jedis.hset("test:hash:memory", "key" + i, "value" + i);}
}

执行完毕后，查看这个Key的大小：

2）方案一：拆分为string类型

id:0	value0
......	......
id:99999	value99999

但该方案也存在一些问题：string结构底层没有太多内存优化，内存占用较多；想要批量获取这些数据比较麻烦。

编写一个单元测试，往Redis存入100000条数据：

@Test
public void testHashMemory2() {for (int i = 0; i < 100000; i++) {jedis.set("test:hash:memory:" + i,  "value" + i);}
}

执行完毕后，查看这个Key的大小：

3）方案二：拆分为小的hash

key:0	id:00	value0
	......	......
	id:99	value99
key:1	id:00	value100
	......	......
	id:99	value199
......
key:999	id:00	value99900
	......	......
	id:99	value99999

编写一个单元测试，往Redis存入100000条数据：

@Test
public void testHashMemory3() {int hashSize = 100;Map<String, String> map = new HashMap<>(hashSize);for (int i = 1; i <= 100000; i++) {int k = (i - 1) / hashSize;int v = i % hashSize;map.put("key_" + v, "value_" + v);if (v == 0) {jedis.hmset("test:small:hash_" + k, map);}}
}