Redis 很屌,不懂使用规范就糟蹋了

Posted 架构师社区

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis 很屌,不懂使用规范就糟蹋了相关的知识,希望对你有一定的参考价值。

命名,才能提供可读性强、可维护性高的 key,便于定位问题和寻找数据。
  • value要避免出现 bigkey、选择高效的序列化和压缩、使用对象共享池、选择高效恰当的数据类型(可参考《Redis 实战篇:巧用数据类型实现亿级数据统计》)。
  • 语意,就好比根据不同的场景我们建立不同的数据库。

    敲黑板

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

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

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

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

    的读写操作就会阻塞线程,降低 Redis 的处理效率。

    bigkey包含两种情况:

  • 键值对的 value很大,比如 value保存了 2MBString数据;
  • 键值对的 value是集合类型,元素很多,比如保存了 5 万个元素的 List 集合。
  • 虽然 Redis 官方说明了 keystring类型 value限制均为512MB

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

    数据压缩来减小数据大小:

    /**
     * 使用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

    你好,我是Redis,一个叫Antirez的男人把我带到了这个世界上。

    说起我的诞生,跟关系数据库MySQL还挺有渊源的。

    在我还没来到这个世界上的时候,MySQL过的很辛苦,互联网发展的越来越快,它容纳的数据也越来越多,用户请求也随之暴涨,而每一个用户请求都变成了对它的一个又一个读写操作,MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子,都是MySQL受苦受难的日子。

    据后来MySQL告诉我说,其实有一大半的用户请求都是读操作,而且经常都是重复查询一个东西,浪费它很多时间去进行磁盘I/O。

    后来有人就琢磨,是不是可以学学CPU,给数据库也加一个缓存呢?于是我就诞生了!

    出生不久,我就和MySQL成为了好朋友,我们俩常常携手出现在后端服务器中。

    应用程序们从MySQL查询到的数据,在我这里登记一下,后面再需要用到的时候,就先找我要,我这里没有再找MySQL要。

    为了方便使用,我支持好几种数据结构的存储:

    因为我把登记的数据都记录在内存中,不用去执行慢如蜗牛的I/O操作,所以找我要比找MySQL要省去了不少的时间呢。

    可别小瞧这简单的一个改变,我可为MySQL减轻了不小的负担!随着程序的运行,我缓存的数据越来越多,有相当部分时间我都给它挡住了用户请求,这一下它可乐得清闲自在了!

    有了我的加入,网络服务的性能提升了不少,这都归功于我为数据库挨了不少枪子儿。

    缓存过期 && 缓存淘汰

    不过很快我发现事情不妙了,我缓存的数据都是在内存中,可是就算是在服务器上,内存的空间资源还是很有限的,不能无节制的这么存下去,我得想个办法,不然吃枣药丸。

    不久,我想到了一个办法:给缓存内容设置一个超时时间,具体设置多长交给应用程序们去设置,我要做的就是把过期了的内容从我里面删除掉,及时腾出空间就行了。

    超时时间有了,我该在什么时候去干这个清理的活呢?

    最简单的就是定期删除,我决定100ms就做一次,一秒钟就是10次!

    我清理的时候也不能一口气把所有过期的都给删除掉,我这里面存了大量的数据,要全面扫一遍的话那不知道要花多久时间,会严重影响我接待新的客户请求的!

    时间紧任务重,我只好随机选择一部分来清理,能缓解内存压力就行了。

     

    就这样过了一段日子,我发现有些个键值运气比较好,每次都没有被我的随机算法选中,每次都能幸免于难,这可不行,这些长时间过期的数据一直霸占着不少的内存空间!气抖冷!

    我眼里可揉不得沙子!于是在原来定期删除的基础上,又加了一招:

    那些原来逃脱我随机选择算法的键值,一旦遇到查询请求,被我发现已经超期了,那我就绝不客气,立即删除。

    这种方式因为是被动式触发的,不查询就不会发生,所以也叫惰性删除!

    可是,还是有部分键值,既逃脱了我的随机选择算法,又一直没有被查询,导致它们一直逍遥法外!而于此同时,可以使用的内存空间却越来越少。

    而且就算退一步讲,我能够把过期的数据都删除掉,那万一过期时间设置的很长,还没等到我去清理,内存就吃满了,一样要吃枣药丸,所以我还得想个办法。

    我苦思良久,终于憋出了个大招:内存淘汰策略,这一次我要彻底解决问题!

    我提供了8种策略供应用程序选择,用于我遇到内存不足时该如何决策:

    有了上面几套组合拳,我再也不用担心过期数据多了把空间撑满的问题了~

    缓存穿透 && 布隆过滤器

    我的日子过的还挺舒坦,不过MySQL大哥就没我这么舒坦了,有时候遇到些烦人的请求,查询的数据不存在,MySQL就要白忙活一场!不仅如此,因为不存在,我也没法缓存啊,导致同样的请求来了每次都要去让MySQL白忙活一场。我作为缓存的价值就没得到体现啦!这就是人们常说的缓存穿透。

     

     这一来二去,MySQL大哥忍不住了:“唉,兄弟,能不能帮忙想个办法,把那些明知道不会有结果的查询请求给我挡一下”

    这时我想到了我的另外一个好朋友:布隆过滤器

    我这位朋友别的本事没有,就擅长从超大的数据集中快速告诉你查找的数据存不存在(悄悄告诉你,我的这位朋友有一点不靠谱,它告诉你存在的话不能全信,其实有可能是不存在的,不过它他要是告诉你不存在的话,那就一定不存在)。

     

    如果你对我这位朋友感兴趣的话,可以看看这里《白话布隆过滤器BloomFilter》

    我把这位朋友介绍给了应用程序,不存在的数据就不必去叨扰MySQL了,轻松帮忙解决了缓存穿透的问题。

    缓存击穿 && 缓存雪崩

    这之后过了一段时间太平日子,直到那一天···

    有一次,MySQL那家伙正优哉游哉的摸鱼,突然一大堆请求给他怼了过去,给他打了一个措手不及。

    一阵忙活之后,MySQL怒气冲冲的找到了我,“兄弟,咋回事啊,怎么一下子来的这么猛”

    我查看了日志,赶紧解释到:“大哥,实在不好意思,刚刚有一个热点数据到了过期时间,被我删掉了,不巧的是随后就有对这个数据的大量查询请求来了,我这里已经删了,所以请求都发到你那里来了”

    “你这干的叫啥事,下次注意点啊”,MySQL大哥一脸不高兴的离开了。

    这一件小事我也没怎么放在心上,随后就抛之脑后了,却没曾想几天之后竟捅了更大的篓子。

    那一天,又出现了大量的网络请求发到了MySQL那边,比上一次的规模大得多,MySQL大哥一会儿功夫就给干趴下了好几次!

    等了好半天这一波流量才算过去,MySQL才缓过神来。

    “老弟,这一次又是什么原因?”,MySQL大哥累的没了力气。

    “这一次比上一次更不巧,这一次是一大批数据几乎同时过了有效期,然后又发生了很多对这些数据的请求,所以比起上一次这规模更大了”

    MySQL大哥听了眉头一皱,“那你倒是想个办法啊,三天两头折磨我,这谁顶得住啊?”

    “其实我也很无奈,这个时间也不是我设置的,要不我去找应用程序说说,让他把缓存过期时间设置的均匀一些?至少别让大量数据集体失效”

    “走,咱俩一起去”

    后来,我俩去找应用程序商量了,不仅把键值的过期时间随机了一下,还设置了热点数据永不过期,这个问题缓解了不少。哦对了,我们还把这两次发生的问题分别取了个名字:缓存击穿和缓存雪崩。

    我们终于又过上了舒适的日子···

    彩蛋

    那天,我正在努力工作中,不小心出了错,整个进程都崩溃了。

    当我再次启动后,之前缓存的数据全都没了,暴风雨似的请求再一次全都怼到了MySQL大哥那里。

    唉,要是我能够记住崩溃前缓存的内容就好了···

    预知后事如何,请关注后续精彩······

    往期TOP5文章

    CPU明明8个核,网卡为啥拼命折腾一号核?

    因为一个跨域请求,我差点丢了饭碗

    完了!CPU一味求快出事儿了!

    哈希表哪家强?几大编程语言吵起来了!

    一个HTTP数据包的奇幻之旅

     

    以上是关于Redis 很屌,不懂使用规范就糟蹋了的主要内容,如果未能解决你的问题,请参考以下文章

    Redis 很屌,不懂使用规范就糟蹋了

    Redis 很屌,不懂使用规范就糟蹋了

    Redis 很屌,不懂使用规范就糟蹋了

    这篇文档让你彻底了解Redis,别再说你不懂Redis了!

    还不懂Redis?看完这个故事就明白了!

    还不懂 Redis?看完这个故事就明白了