【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

你可能感兴趣的:(redis,数据库,java)