【Redis】Redis使用规范

Redis 的使用，几乎都是作为缓存中间件的。缓存用得好，当然能提高软件的运行速度，但是缓存用的不好，对于提高速度上也无法带来增益。

键值对使用

• 好的 key 命名，能提供更好的可读性和可维护性，便于定位问题和寻找数据。
• value 要避免出现 bigkey、选择高效的序列化和压缩、使用对象共享池、选择高效恰当的数据类型。

类比于数据库，Redis 的 key 就相当于数据库的 Schema。我们需要在区分不同的数据库表，就是根据不同数据表的命名。对于 NoSQL 类型的 Redis 来说，Key 就表现了不同的数据库表。

业务名:表名:id

Key 过长会导致的问题：

**字符串长度增加，SDS 的元数据也会占用更多的内存空间。**每次读取一个 Key 会需要更多的时间，会发生更多的网络 IO 数据量。

BigKey 会导致的问题：

**BigKey 的读写操作会阻塞线程，降低 Redis 的处理效率。**Redis 的底层会将每次读写操作抽象为文件事件，处理的数据更多，容易造成事件队列的阻塞，影响效率。
防止网卡流量、慢查询，string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000 比较合适。

Redis 的 String 类型的值的大小有限制，最大可以存储 512 MB 的数据。

需要注意的是，在 Redis 中，即使存储的是纯文本，也是被当作二进制数据来处理的。因此，一个字符串的大小会比实际存储的文本数据要大。例如，一个包含 100 个字符的字符串可能会占用 120 个字节的内存空间。这个差异的大小取决于字符串中使用的字符集，UTF-8 编码的字符串可能会比 ASCII 编码的字符串占用更多的内存空间。在使用 Redis 的 String 类型时，需要注意值的大小，避免将过大的值存储到 Redis 中。

如果需要存储大量的数据，有以下两种解决方式：

• 考虑使用 Redis 的其他数据类型，例如 List、Hash 或 Set 等。这些数据类型不会有存储大小的限制，可以存储更多的数据。
• 可以通过 gzip 数据压缩来减小数据大小：

/**
 * 使用gzip压缩字符串
 */
public static String compress(String str) {
    if (str == null || str.length() == 0) {
        return str;
    }

    try (ByteArrayOutputStream out = new ByteArrayOutputStream();
    GZIPOutputStream gzip = new GZIPOutputStream(out)) {
        gzip.write(str.getBytes());
    } catch (IOException e) {
        e.printStackTrace();
    }
    return new sun.misc.BASE64Encoder().encode(out.toByteArray());
}

/**
 * 使用gzip解压缩
 */
public static String uncompress(String compressedStr) {
    if (compressedStr == null || compressedStr.length() == 0) {
        return compressedStr;
    }
    byte[] compressed = new sun.misc.BASE64Decoder().decodeBuffer(compressedStr);;
    String decompressed = null;
    try (ByteArrayOutputStream out = new ByteArrayOutputStream();
    ByteArrayInputStream in = new ByteArrayInputStream(compressed);
    GZIPInputStream ginzip = new GZIPInputStream(in);) {
        byte[] buffer = new byte[1024];
        int offset = -1;
        while ((offset = ginzip.read(buffer)) != -1) {
            out.write(buffer, 0, offset);
        }
        decompressed = out.toString();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return decompressed;
}

集合类型

集合类型需要避免出现 BigKey 的情况。主要有以下这些解决方法：

使用高效序列化和压缩方法

我们在做 Redis 配置的时候，可以选择更高效的序列化方式和压缩方法去减少 value 的大小。

序列化方式优化

protostuff 和 kryo 都是 Java 语言中常用的序列化框架。它们都可以将对象的状态序列化为字节序列，并在需要的时候将字节序列反序列化为对象。

• protostuff 是一个轻量级的序列化框架，它主要用于将 Java 对象序列化为字节序列，并在需要的时候将字节序列反序列化为 Java 对象。它与 Google 的 Protocol Buffers 相似，但比 Protocol Buffers 更轻量级和灵活。protostuff 支持多种数据类型，包括基本类型、对象、集合和数组。
• kryo 是一个高性能的序列化框架，它可以将复杂的对象图序列化为字节序列，并在需要的时候将字节序列反序列化为对象。kryo 支持多种数据类型，包括基本类型、对象、集合和数组。它还支持对象的引用、循环引用和注册类型。

总体来说，protostuff 比 kryo 轻量级和简单，但 kryo 支持的功能更丰富。如果需要对性能要求较高的应用进行序列化，可以考虑使用 kryo。否则，可以使用 protostuff 来进行序列化。

• 为了提高序列化之后的可读性，通常会使用 JSON 或者 XML。
• 为了避免数据占用空间大，可以使用压缩工具（snappy、 gzip）将数据压缩再存到 Redis 中。

使用整数对象共享池

Redis 中有两种类型的对象共享池：整数对象共享池和字符串对象共享池。

整数对象共享池可以让 Redis 在内存中共享相同的整数对象，从而减少内存的使用。字符串对象共享池可以让 Redis 在内存中共享相同的字符串对象，从而减少内存的使用。

但是在 Redis 中，并没有实际使用到字符串对象共享池。这有两个原因：

• 字符串和整数比较的时间复杂度相差很大，前者是 O(n)，后者是 O(1)
• 字符串缓冲池中，字符串的命中率比较低，收益比不高

整数对象共享池

Redis 内部维护了 0 到 9999 这 1 万个整数对象，并把这些整数作为一个共享池使用。即使大量键值对保存了 0 到 9999 范围内的整数，在 Redis 实例中，其实只保存了一份整数对象，可以节省内存空间。

需要注意的是，有两种情况是不生效的：

• Redis 中设置了 maxmemory，而且启用了 LRU策略（allkeys-lru 或 volatile-lru 策略），那么，整数对象共享池就无法使用了。这是因为 LRU 需要统计每个键值对的使用时间，如果不同的键值对都复用一个整数对象就无法统计了。
• 如果集合类型数据采用 ziplist 编码，而集合元素是整数，这个时候，也不能使用共享池。因为 ziplist 使用了紧凑型内存结构，判断整数对象的共享情况效率低。

命令使用规范

生产禁用的指令

Redis 是单线程处理请求操作，如果执行一些涉及大量操作、耗时长的命令，就会严重阻塞主线程，导致其它请求无法得到正常处理。

• KEYS：该命令需要对 Redis 的全局哈希表进行全表扫描，严重阻塞 Redis 主线程；应该使用 SCAN 来代替，分批返回符合条件的键值对，避免主线程阻塞，还可以使用 scan/sscan/zscan/hscan 来进行代替。
• FLUSHALL：删除 Redis 实例上的所有数据，如果数据量很大，会严重阻塞 Redis 主线程；
• FLUSHDB，删除当前数据库中的数据，如果数据量很大，同样会阻塞 Redis 主线程。

加上 ASYNC 选项，让 FLUSHALL，FLUSHDB 异步执行。

我们也可以直接禁用，用 rename-command 命令在配置文件中对这些命令进行重命名，让客户端无法使用这些命令。

rename-command KEYS ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

慎用 MONITOR 命令

MONITOR 命令会把监控到的内容持续写入输出缓冲区。

如果线上命令的操作很多，输出缓冲区很快就会溢出了，这就会对 Redis 性能造成影响，甚至引起服务崩溃。

所以，除非十分需要监测某些命令的执行（例如，Redis 性能突然变慢，需要查看下客户端执行了哪些命令）才使用。

慎用全量操作命令

比如获取集合中的所有元素（HASH 类型的 hgetall、List 类型的 lrange、Set 类型的 smembers、zrange 等命令）。
这些操作会对整个底层数据结构进行全量扫描 ，导致阻塞 Redis 主线程。

如果业务场景就是需要获取全量数据，有两个方式可以解决：

1. 使用 SSCAN、HSCAN等命令分批返回集合数据；
2. 把大集合拆成小集合，比如按照时间、区域等划分。

数据保存规范

冷热数据分离

虽然 Redis 支持使用 RDB 快照和 AOF 日志持久化保存数据，但是，这两个机制都是用来提供数据可靠性保证的，并不是用来扩充数据容量的。

不要什么数据都存在 Redis，应该作为缓存保存热数据，这样既可以充分利用 Redis 的高性能特性，还可以把宝贵的内存资源用在服务热数据上。

业务数据隔离

不要将不相关的数据业务都放到一个 Redis 中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。

设置过期时间

在数据保存时，我建议你根据业务使用数据的时长，设置数据的过期时间。

写入 Redis 的数据会一直占用内存，如果数据持续增多，就可能达到机器的内存上限，造成内存溢出，导致服务崩溃。

控制单实例的内存容量

建议设置在 2~6 GB 。这样一来，无论是 RDB 快照，还是主从集群进行数据同步，都能很快完成，不会阻塞正常请求的处理。

防止缓存雪崩

避免集中过期 key 导致缓存雪崩。

什么是缓存雪崩？

当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。

运维规范

1. 使用 Cluster 集群或者哨兵集群，做到高可用；
2. 实例设置最大连接数，防止过多客户端连接导致实例负载过高，影响性能。
3. 不开启 AOF 或开启 AOF 配置为每秒刷盘，避免磁盘 IO 拖慢 Redis 性能。
4. 设置合理的 repl-backlog，降低主从全量同步的概率
5. 设置合理的 slave client-output-buffer-limit，避免主从复制中断情况发生。
6. 根据实际场景设置合适的内存淘汰策略。
7. 使用连接池操作 Redis。

参考文档：

https://mp.weixin.qq.com/s/m0dPby4YAwbHzA-Yg-nwvQ