规范：Redis规范

在公司项目中，redis属于高频使用，在使用中，我们遇到了各种各样的redis问题，于是针对自身情况梳理了一个redis使用规范。

一、键名设计

1、key名设计

1. 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符)

2. 建议以业务名为前缀，以冒号分割来构造一定规则的key名(比如业务名:表名:id)

比如:teach:leeson_id:21

可读性和可管理性

以业务名 (或数据库名) 为前缀(防止 key 冲突)，用冒号分隔，比如业务名: 表名: id

复制代码

ugc:video:1

简洁性

保证语义的前提下，控制 key 的长度，当 key 较多时，内存占用也不容忽视，例如：

复制代码

user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}。

不要包含特殊字符

反例：包含空格、换行、单双引号以及其他转义字符

3. 控制key的长度

key太长量一大起来就会非常占用内存

2、value设计

1. 拒绝大key操作

禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。

错误示范：直接将laravel的整个模型或者对象当成value存储

防止网卡流量、慢查询，string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000。

反例：一个包含 200 万个元素的 list。

非字符串的 bigkey，不要使用 del 删除，使用 hscan、sscan、zscan 方式渐进式删除，同时要注意防止 bigkey 过期时间自动删除问题 (例如一个 200 万的 zset 设置 1 小时过期，会触发 del 操作，造成阻塞，而且该操作不会不出现在慢查询中 (latency 可查))，查找方法和删除方法

2. 设计key时使用合适的数据类型(在资源利用和性能之间作平衡)

错误示范：一个普通字符串弄成hash类型进行存储

例如：实体类型 (要合理控制和使用数据结构内存编码优化配置, 例如 ziplist，但也要注意节省内存和性能之间的平衡)

反例：

复制代码

set user:1:name tom
set user:1:age 19
set user:1:favor football

正例：

复制代码

hmset user:1 name tom age 19 favor football

3. 一定要控制key的生命周期

错误示范：key设置为永不过期

redis 不是垃圾桶，建议使用 expire 设置过期时间 (条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注 idletime。

4. 控制value长度

比如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。

5. 数据按需存储

不需要的数据千万不要存储在redis，只会浪费内存空间

二、命令使用

1.禁止使用keys、flushall、hmgetall等命令

为防止业务研发的误操作，通常可以在交付redis实例之前将默认命令rename掉；而真正需要删除或者遍历key时可以使用scan家族命令

2.慎用hgetall、lrange、smembers、zrange等命令

除非业务场景需要，尽量不要使用这些命令。如果没有控制好会导致操作量过大，形成阻塞。

三、缓存设计

1. 多个库的使用

如果应用中会涉及到各种不同的redis数据存储，应该分库存储，最好是一种业务使用一个库

比如：课程缓存:库1；订单队列:库2；日志处理:库3

2.避免多个应用公用一个redis实例

避免一个应用出现问题或者错误使用拖累其他应用

3.合理评估业务场景，并设置最大内存以及内存淘汰策略(maxmemory和maxmemory-policy)

目前我们用的阿里云redis，不太存在这个问题

4.使用带有连接池的数据库，可以有效控制连接，同时提高效率

5.给redis设置一个密码

目前我们用的阿里云redis，不太存在这个问题

6.冷热数据区分

虽然 Redis支持持久化，但将所有数据存储在redis中，成本非常昂贵。

建议将热数据 (如 QPS超过 5k) 的数据加载到redis中。

低频数据可存储在Mysql、ElasticSearch中。

7.缓存非特殊情况不做中间态redis大多数时候都是做缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。

缓存的高可用会影响业务；
产生深耦合会发生无法预料的效果；
会对维护产生负效果。

四、场景实战问题

1、项目redis使用问题

当前的使用方式是，每个接入的应用要配置核心项目的redis配置。这样是不合理的，核心项目的redis应该只能在核心项目中使用，对外应该是提供api接口或者rpc进行访问。

2、慎用laravel自带的cache功能

laravel自带的cache功能最容易导致大key，经常由于简单使用至今将整个对象模型存储到redis，造成大key。

3、注意key的过期时间设置

在报名等高峰期的时候，key值设置过短容易造成缓存穿透，导致大量请求直接打到mysql数据库。

4、小心缓存穿透

经常使用会只给有数据的结果进行缓存，结果导致空数据无法缓存，相同查询直接每次都到达数据库，所以空值也应该被缓存。

5、慎用缓存层层包裹

缓存里面的数据还有一层缓存数据，会导致问题排查麻烦，出问题也不容易处理。

6、慎用将redis做为消息队列

如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。

如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ，nsq,(花园同步有时间前后要求，且量不大才使用的)。

五、查询使用问题

1、线上Redis禁止使用Keys正则匹配操作

redis是单线程处理，在线上Key数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成redis服务崩溃！如果有类似需求，请使用scan命令代替。

1、O(N) 命令关注 N 的数量

例如 hgetall、lrange、smembers、zrange、sinter 等并非不能使用，但是需要明确 N 的值。有遍历的需求可以使用 hscan、sscan、zscan 代替。

2、禁用命令

禁止线上使用 keys、flushall、flushdb 等，通过 redis 的 rename 机制禁掉命令，或者使用 scan 的方式渐进式处理。

3、合理使用 select

redis 的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。

4、使用批量操作提高效率

原生命令：例如 mget、mset。
非原生命令：可以使用 pipeline 提高效率。

但要注意控制一次批量操作的元素个数 (例如 500 以内，实际也和元素字节数有关)。

注意两者不同：

原生是原子操作，pipeline 是非原子操作。
pipeline 可以打包不同的命令，原生做不到
pipeline 需要客户端和服务端同时支持。

5、不建议过多使用 Redis 事务功能

Redis 的事务功能较弱 (不支持回滚)，而且集群版本(自研和官方) 要求一次事务操作的 key 必须在一个 slot 上(可以使用 hashtag 功能解决)

6、Redis 集群版本在使用 Lua 上有特殊要求

1、所有 key 都应该由 KEYS 数组来传递，redis.call/pcall 里面调用的 redis 命令，key 的位置，必须是 KEYS array, 否则直接返回 error，"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS arrayrn"

2、所有 key，必须在 1 个 slot 上，否则直接返回 error, "-ERR eval/evalsha command keys must in same slotrn"

7、monitor 命令

必要情况下使用 monitor 命令时，要注意不要长时间使用。

三、客户端使用

1、避免多个应用使用一个 Redis 实例

不相干的业务拆分，公共数据做服务化。

2、使用连接池

可以有效控制连接，同时提高效率，标准使用方式：

复制代码

执行命令如下：
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    //具体的命令
    jedis.executeCommand()
} catch (Exception e) {
    logger.error("op key {} error: " + e.getMessage(), key, e);
} finally {
    //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
    if (jedis != null)
        jedis.close();
}

3、熔断功能

高并发下建议客户端添加熔断功能 (例如 netflix hystrix)

4、合理的加密

设置合理的密码，如有必要可以使用 SSL 加密访问（阿里云 Redis 支持）

5、淘汰策略

根据自身业务类型，选好 maxmemory-policy(最大内存淘汰策略)，设置好过期时间。

默认策略是 volatile-lru，即超过最大内存后，在过期键中使用 lru 算法进行 key 的剔除，保证不过期数据不被删除，但是可能会出现 OOM 问题。

其他策略如下：

allkeys-lru：根据 LRU 算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random: 随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的 ttl 属性，删除最近将要过期数据。如果没有，回退到 noeviction 策略。
noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息 "(error) OOM command not allowed when used memory"，此时 Redis 只响应读操作。

其他

1、redis同步工具

阿里云的redis-shake工具，方便快速；redis 间数据同步可以使用：redis-port

2、大key查询

阿里云有大key分析工具；redis 大 key 搜索工具

3、热点 key 寻找

内部实现使用 monitor，所以建议短时间使用 facebook 的 redis-faina 阿里云 Redis 已经在内核层面解决热点 key 问题

4、删除 bigkey

下面操作可以使用 pipeline 加速。
redis 4.0 已经支持 key 的异步删除，欢迎使用。

1、Hash 删除: hscan + hdel

复制代码

public void delBigHash(String host, int port, String password, String bigHashKey) {
    Jedis jedis = new Jedis(host, port);
    if (password != null && !"".equals(password)) {
        jedis.auth(password);
    }
    ScanParams scanParams = new ScanParams().count(100);
    String cursor = "0";
    do {
        ScanResult<Entry<String, String>> scanResult = jedis.hscan(bigHashKey, cursor, scanParams);
        List<Entry<String, String>> entryList = scanResult.getResult();
        if (entryList != null && !entryList.isEmpty()) {
            for (Entry<String, String> entry : entryList) {
                jedis.hdel(bigHashKey, entry.getKey());
            }
        }
        cursor = scanResult.getStringCursor();
    } while (!"0".equals(cursor));
    //删除bigkey
    jedis.del(bigHashKey);
}

2、List 删除: ltrim

复制代码

public void delBigList(String host, int port, String password, String bigListKey) {
    Jedis jedis = new Jedis(host, port);
    if (password != null && !"".equals(password)) {
        jedis.auth(password);
    }
    long llen = jedis.llen(bigListKey);
    int counter = 0;
    int left = 100;
    while (counter < llen) {
        //每次从左侧截掉100个
        jedis.ltrim(bigListKey, left, llen);
        counter += left;
    }
    //最终删除key
    jedis.del(bigListKey);
}

3、Set 删除: sscan + srem

复制代码

public void delBigSet(String host, int port, String password, String bigSetKey) {
    Jedis jedis = new Jedis(host, port);
    if (password != null && !"".equals(password)) {
        jedis.auth(password);
    }
    ScanParams scanParams = new ScanParams().count(100);
    String cursor = "0";
    do {
        ScanResult<String> scanResult = jedis.sscan(bigSetKey, cursor, scanParams);
        List<String> memberList = scanResult.getResult();
        if (memberList != null && !memberList.isEmpty()) {
            for (String member : memberList) {
                jedis.srem(bigSetKey, member);
            }
        }
        cursor = scanResult.getStringCursor();
    } while (!"0".equals(cursor));
    //删除bigkey
    jedis.del(bigSetKey);
}

4、SortedSet 删除: zscan + zrem

复制代码

public void delBigZset(String host, int port, String password, String bigZsetKey) {
    Jedis jedis = new Jedis(host, port);
    if (password != null && !"".equals(password)) {
        jedis.auth(password);
    }
    ScanParams scanParams = new ScanParams().count(100);
    String cursor = "0";
    do {
        ScanResult<Tuple> scanResult = jedis.zscan(bigZsetKey, cursor, scanParams);
        List<Tuple> tupleList = scanResult.getResult();
        if (tupleList != null && !tupleList.isEmpty()) {
            for (Tuple tuple : tupleList) {
                jedis.zrem(bigZsetKey, tuple.getElement());
            }
        }
        cursor = scanResult.getStringCursor();
    } while (!"0".equals(cursor));
    //删除bigkey
    jedis.del(bigZsetKey);
}