第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 {
    
        // 扫描并获取一部分Key
        ScanResult<String> result = jedis.scan(cursor);
        // 记录此时的cursor
        cursor = result.getCursor();
        List<String> list = result.getResult();
        if (list == null || list.isEmpty()) {
    
            break;
        }
        // 遍历这一部分Key
        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;
            }
            // 如果查询出来的长度超过自定义的长度，则是BigKey
            if (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字符串

login:user:1

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

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

• 2）字段打散

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

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

• 3）hash（推荐）

login:user:1	name	Jack
	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);
        }
    }
}

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

对比以上两种方案可以发现，拆分成小hash的方式最省空间。

7.1.4 小结

• Key的最佳实践

  • 固定格式：[业务名]:[数据名]:[id]
  • 足够简短：不超过44字节
  • 不包含特殊字符

• Value的最佳实践

  • 合理的拆分数据，拒绝BigKey
  • 选择合适数据结构
  • Hash结构的entry数量不要超过1000
  • 设置合理的超时时间

…

本节完。

更多内容请查阅分类专栏：Redis从入门到精通

本节所涉及的代码和资源可从git仓库下载：https://gitee.com/weidag/redis_learning.git

感兴趣的读者还可以查阅我的另外几个专栏：

• SpringBoot源码解读与原理分析(已完结)
• MyBatis3源码深度解析(已完结)
• 再探Java为面试赋能(持续更新中…)