让你的 Redis 起飞的键值设计规范

业务在使用 Redis 过程中可能会经常遇到各种各样的问题，今天我们先从 Redis 键值对设计的角度出发，看下常见因键值对设计不合理影响的业务一些情况，以及应该如何优化。

本文主要分为以下两部分：

1. key 命名规范

2. value 设计规范

key 的命名规范是非常重要的， 这在海量KV的治理场景下，是一个特别重要的优化点。一个好的命名规范，既可以具体有良好的可管理性，又可以节省内存。

redis> GET regv:uid:100123 
"zhangsan"

key 命名模版如下:

简单解释一下 regv:uid:100123的命名规则:

• regv:  业务服务名称

• uid:   字段逻辑含义

• 100123:  具体业务ID

该模版依然可以简化，具体如下:

整体建议使用以上 key 命名模版常规版或者精简版，补充描述信息可以在 [opt] 中添加, {uid}存放对应具体业务ID。

我们再看下一些不建议使用的例子：

// 反例 1 
redis> SET registryservice:userid:string:100123 "zhangsan"
OK
// 反例 2
redis> SET 6B1B0C32-C2C5-4E48-B6BC-DEFA25E41919 "zhangsan"
OK
// 反例 3
redis> SET "!@#/:$%^&*()+100123" "zhangsan"
OK
// 反例 4
redis> SET "a b c d 100123" "sometext"
OK

这些个例子中，

反例 1：key 太长，这个key的长度甚至大于value长度，优点是描述信息很明确，缺点就是浪费内存

反例 2：在反例1的基础上，KEY本身是个UUID，缺点：key 太长、含义无可读性，无法scan

反例 3：在反例2的基础上，增加了特殊字符，缺点：无可读性，部分场景下会引发业务异常

反例 4：key 中包含了空格，缺点：无可读性，部分场景下引发业务歧义

先说原因，就是避免内存浪费。

在 Redis 中 key 就是字符串（String）类型，value 可以是 string、hash、list、set、zset等类型。

再看下影响 key 内存占用的几个关键数据结构：

这个属于通用数据结构，每个键值对都会包含 redisObject 数据结构。

typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    struct evictionPoolEntry *eviction_pool;    /* Eviction pool of keys */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

    影响 Redis key 占用内存的因素：

1. key 的长度，如果过长，内部编码会从 embstr 变为 raw，相对增大了内存开销；

2. 过期设置

1. 以英文字母开头

2. 建议只是用小写字母、数字、冒号

3. 不要包含特殊字符

4. 不通描述信息，需要用冒号分割

5. key不要太长，能缩写就缩写

1. 禁止上线 bigkey

2. 善用数据类型

3. 压缩数据

4. 过期设置