Redis 很屌，不懂使用规范就糟蹋了_redis缓存一个集合需要拆分成多个对象吗-优快云博客

这可能是最中肯的 Redis 使用规范了

码哥，昨天我被公司 Leader 批评了。

我在单身红娘婚恋类型互联网公司工作，在双十一推出下单就送女朋友的活动。

谁曾想，凌晨 12 点之后，用户量暴增，出现了一个技术故障，用户无法下单，当时老大火冒三丈！

经过查找发现 Redis 报 Could not get a resource from the pool 。

获取不到连接资源，并且集群中的单台 Redis 连接量很高。

于是各种更改最大连接数、连接等待数，虽然报错信息频率有所缓解，但还是 持续报错 。

后来经过线下测试，发现存放 Redis 中的 字符数据很大，平均 1s 返回数据 。

❝

码哥，可以分享下使用 Redis 的规范么？我想做一个唯快不破的真男人！

Redis 使用规范围绕如下几个纬度展开：

键值对使用规范；
命令使用规范；
数据保存规范；
运维规范。

键值对使用规范

有两点需要注意：

好的 key 命名，才能提供可读性强、可维护性高的 key，便于定位问题和寻找数据。
value 要避免出现 bigkey 、选择高效的序列化和压缩、使用对象共享池、选择高效恰当的数据类型（可参考《Redis 实战篇：巧用数据类型实现亿级数据统计》）。

key 命名规范

规范的 key 命名，在遇到问题的时候能够方便定位。Redis 属于没有 Scheme 的 NoSQL 数据库。

所以要靠规范来建立其 Scheme 语意，就好比根据不同的场景我们建立不同的数据库。

敲黑板

把「业务模块名」作为前缀（好比数据库 Scheme ），通过「冒号」分隔，再加上「具体业务名」。

这样我们就可以通过 key 前缀来区分不同的业务数据，清晰明了。

总结起来就是：「业务名:表名:id」

比如我们要统计公众号属于技术类型的博主「码哥字节」的粉丝数。

set 公众号:技术类:码哥字节 100000

❝

码哥，key 太长的话有什么问题么？

key 是字符串，底层的数据结构是 SDS ，SDS 结构中会包含字符串长度、分配空间大小等元数据信息。

字符串长度增加，SDS 的元数据也会占用更多的内存空间。

所以当字符串太长的时候，我们可以采用适当缩写的形式。

不要使用 bigkey

❝

码哥，我就中招了，导致报错获取不到连接。

因为 Redis 是单线程执行读写指令，如果出现bigkey的读写操作就会阻塞线程，降低 Redis 的处理效率。

bigkey 包含两种情况：

value value 2MB String
键值对的 value 是集合类型，元素很多，比如保存了 5 万个元素的 List 集合。

虽然 Redis 官方说明了 key 和 string 类型 value 限制均为 512MB 。

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

❝

码哥，如果业务数据就是这么大咋办？比如保存的是《金瓶梅》这个大作。

我们还可以通过 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;
}

集合类型

如果集合类型的元素的确很多，我们可以将一个大集合拆分成多个小集合来保存。

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

为了节省内存，我们可以使用高效的序列化方法和压缩方法去减少 value 的大小。

protostuff 和 kryo 这两种序列化方法，就要比 Java 内置的序列化方法效率更高。

上述的两种序列化方式虽然省内存，但是序列化后都是二进制数据，可读性太差。

通常我们会序列化成 JSON 或者 XML ，为了避免数据占用空间大，我们可以使用压缩工具（snappy、 gzip）将数据压缩再存到 Redis 中。

使用整数对象共享池

Redis 内部维护了 0 到 9999 这 1 万个整数对象，并把这些整数作为一个共享池使用。

即使大量键值对保存了 0 到 9999 范围内的整数，在 Redis 实例中，其实只保存了一份整数对象，可以节省内存空间。

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

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

命令使用规范

有的命令的执行会造成很大的性能问题，我们需要格外注意。

生产禁用的指令

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

KEYS：该命令需要对 Redis 的全局哈希表进行全表扫描，严重阻塞 Redis 主线程；❝应该使用 SCAN 来代替，分批返回符合条件的键值对，避免主线程阻塞。
FLUSHALL：删除 Redis 实例上的所有数据，如果数据量很大，会严重阻塞 Redis 主线程；
FLUSHDB，删除当前数据库中的数据，如果数据量很大，同样会阻塞 Redis 主线程。❝加上 ASYNC 选项，让 FLUSHALL，FLUSHDB 异步执行。

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