乐趣区

关于java:Redis-很屌不懂使用规范就糟蹋了

jiezi

这可能是最中肯的 Redis 应用标准了

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

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

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

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

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

于是各种更改最大连接数、连贯期待数，尽管报错信息频率有所缓解，但还是 继续报错。

起初通过线下测试，发现寄存 Redis 中的 字符数据很大，均匀 1s 返回数据。

码哥，能够分享下应用 Redis 的标准么？我想做一个唯快不破的真男人！

通过 Redis 为什么这么快？这篇文章咱们晓得 Redis 为了高性能和节俭内存吃力心理。

所以，只有标准的应用 Redis，能力实现高性能和节俭内存，否则再屌的 Redis 也禁不起咱们瞎折腾。

Redis 应用标准围绕如下几个纬度开展：

  • 键值对应用标准；
  • 命令应用标准；
  • 数据保留标准；
  • 运维标准。

键值对应用标准

有两点须要留神：

  1. 好的 key 命名，能力提供可读性强、可维护性高的 key，便于定位问题和寻找数据。
  2. 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 实例中，其实只保留了一份整数对象，能够节俭内存空间。

须要留神的是，有两种状况是不失效的：

  1. Redis 中设置了 maxmemory，而且启用了 LRU策略（allkeys-lru 或 volatile-lru 策略），那么，整数对象共享池就无奈应用了。

    这是因为 LRU 须要统计每个键值对的应用工夫，如果不同的键值对都复用一个整数对象就无奈统计了。

  2. 如果汇合类型数据采纳 ziplist 编码，而汇合元素是整数，这个时候，也不能应用共享池。

    因为 ziplist 应用了紧凑型内存构造，判断整数对象的共享状况效率低。

命令应用标准

有的命令的执行会造成很大的性能问题，咱们须要分外留神。

生产禁用的指令

Redis 是单线程解决申请操作，如果咱们执行一些波及大量操作、耗时长的命令，就会重大阻塞主线程，导致其它申请无奈失去失常解决。

  • KEYS：该命令须要对 Redis 的全局哈希表进行全表扫描，重大阻塞 Redis 主线程；

    应该应用 SCAN 来代替，分批返回符合条件的键值对，防止主线程阻塞。

  • FLUSHALL：删除 Redis 实例上的所有数据，如果数据量很大，会重大阻塞 Redis 主线程；

  • FLUSHDB，删除以后数据库中的数据，如果数据量很大，同样会阻塞 Redis 主线程。

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

咱们也能够间接禁用，用 rename-command 命令在配置文件中对这些命令进行重命名，让客户端无奈应用这些命令。

慎用 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。

最初，欢送在留言区分享一下你罕用的应用标准，咱们一起交换探讨。

好文举荐

Redis 外围篇：为什么这么快

Redis 长久化篇：AOF 与 RDB 如何保证数据高可用

Redis 高可用篇：主从架构数据一致性同步原理

Redis 高可用篇：哨兵集群原理

Redis 高可用篇：Cluster 集群原理

Redis 实战篇：巧用 Bitmap 实现亿级海量数据统计

Redis 实战篇：通过 Geo 类型实现左近的人邂逅女神

Redis 新个性篇：多线程模型解读

Redis 6.0 新个性篇：客户端缓存带来的反动

退出移动版