乐趣区

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

这可能是最中肯的 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 属于 没有 SchemeNoSQL数据库。

所以要靠标准来建设其 Scheme 语意,就好比依据不同的场景咱们建设不同的数据库。

敲黑板

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

这样咱们就能够通过 key 前缀来辨别不同的业务数据,清晰明了。

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

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

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

码哥,key 太长的话有什么问题么?

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

字符串长度减少,SDS 的元数据也会占用更多的内存空间。

所以当字符串太长的时候,咱们能够采纳适当缩写的模式。

不要应用 bigkey

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

因为 Redis 是单线程执行读写指令,如果呈现bigkey 的读写操作就会阻塞线程,升高 Redis 的解决效率。

bigkey蕴含两种状况:

  • 键值对的 value很大,比方 value保留了 2MBString数据;
  • 键值对的 value是汇合类型,元素很多,比方保留了 5 万个元素的 List 汇合。

尽管 Redis 官网阐明了 keystring 类型 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的大小。

protostuffkryo这两种序列化办法,就要比 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 新个性篇:客户端缓存带来的反动

退出移动版