一、前言

在互联网利用中，缓存成为高并发架构的要害组件。这篇博客次要介绍缓存应用的典型场景、实操案例剖析、Redis应用标准及惯例 Redis 监控。

二、常见缓存比照

常见的缓存计划，有本地缓存，包含HashMap/ConcurrentHashMap、Ehcache、Memcache、Guava Cache等，缓存中间件包含Redis、Tair等。

三、Redis应用场景

1. 计数

Redis实现疾速计数及缓存性能。

例如：视频或直播在线观看人数，用户每播放一次，就会自增1。

2. Session集中管理

Session能够存储在应用服务是JVM中，但这一种计划会有一致性的问题，还有高并发下，会引发JVM内存溢出。Redis将用户的Session集中管理，这种状况下只有保障Redis的高可用和扩展性，每次用户更新或查问登录都间接从Redis中信息获取。

3.限速

例如：业务要求用户一分钟内，只能获取5次验证码。

4.排行榜

关系型数据库在排行榜方面查问速度广泛偏慢，所以能够借助redis的SortedSet进行热点数据的排序。

比方在我的项目中，如果须要统计主播的吸金排行榜，能够以主播的id作为member, 当天打赏的流动礼物对应的热度值作为 score, 通过zrangebyscore就能够获取主播流动日榜。

5.分布式锁

在理论的多过程并发场景下，应用分布式锁来限度程序的并发执行。多用于避免高并发场景下，缓存被击穿的可能。

分布式锁的理论就是"占坑"，当另一个过程来执行setnx时，发现标识位曾经为1，只好放弃或者期待。

四、案例解析

1、【案例】过期设置- set命令会去掉过期工夫

Redis所有的数据结构，都能够设置过期工夫。如果一个字符串曾经设置了过期工夫，而后从新设置它，会导致过期工夫隐没。所以在我的项目中须要正当评估Redis容量，防止因为频繁set导致没有过期策略，间接导致内存被占满。

如下是 Redis 源码截图：

2、【案例】对于 Jedis 2.9.0 及以下版本过期设置 BUG

发现Jedis在进行expiredAt命令调用时有bug，最终调用的是pexpire命令，这个bug会导致key过期工夫很长，导致Redis内存溢出等问题。倡议降级到Jedis 2.9.1及以上版本。

BinaryJedisCluster.java源码如下：

@Override  public Long pexpireAt(final byte[] key, final long millisecondsTimestamp) {    return new JedisClusterCommand<Long>(connectionHandler, maxAttempts) {      @Override      public Long execute(Jedis connection) {        return connection.pexpire(key, millisecondsTimestamp); //此处pexpire应该是pexpireAt      }    }.runBinary(key);  }

比照pexpire和pexpireAt：

比方咱们以后应用的工夫是2018-06-14 17:00:00，它的unix工夫戳为1528966800000毫秒，当咱们应用PEXPIREAT命令时，因为是过来的工夫，相应的key会立刻过期。

而咱们误用了PEXPIRE命令时，key不会立刻过期，而是等到1528966800000毫秒后才过期，key过期工夫会相当长，约几W天后，从而可能导致Redis内存溢出、服务器解体等问题。

3、【案例】缓存被击穿

缓存的key有过期策略，如果恰好在这个工夫点对这个Key有大量的并发申请，这些申请发现缓存过期个别都会从后端DB回源数据并回设到缓存，这个时候大并发的申请可能会霎时把后端DB压挂。

业界罕用优化计划有两种：

第一种：应用分布式锁，保障高并发下，仅有一个线程能回源后端DB。

第二种：保障高并发的申请到的Redis key始终是无效的，应用非用户申请回源后端，改成被动回源。个别能够应用异步工作进行缓存的被动刷新。

4、【案例】Redis-standalone架构禁止应用非0库

Redis执行命令select 0和select 1切换，造成性能损耗。

RedisTemplate在执行execute办法的时候会先获取链接。

执行到RedisConnectionUtils.java，会有一段获取链接的办法。

JedisConnectionFactory.java 会调用JedisConnection结构器，留神这边的dbIndex就是数据库编号，如：1

持续跟进JedisConnection代码，当抉择库大于1时，会有select db操作。如果始终应用0库是不须要额定执行切库命令的。晓得了第一个切库select 1的中央，那么select 0是哪来的呢？

其实客户端应用Redis也会是要开释链接的，只不过RedisTemplate曾经帮咱们主动开释了，让咱们再回到一开始RedisTemplate执行execute(...)办法的中央。

上面还是RedisConnectionUtils.java，执行链接敞开的代码。

按代码正文的意思，如果抉择库编号不为0，spring-data-redis框架每次都会执行重置select 0！

笔者在vivo商城业务中，商品详情页接口通过下面的调优，性能进步了3倍多。

进一步验证数据库切换至多影响性能3倍左右（视具体业务而定）。

Rediscluster集群数据库，默认0库，无奈抉择其余数据库，也就防止了这个问题。

5、【案例】当心工夫复杂度o(n)Redis命令

Redis是单线程的，所以线程平安的。

Redis应用非阻塞IO，并且大部分命令的工夫复杂度O(1)。

应用高耗时的命令是十分危险的，会占用惟一的一个线程的大量解决工夫，导致所有的申请都被拖慢。

例如：获取所有set汇合中的元素 smembers myset，返回指定Hash中所有的member，工夫复杂度O(N)。

缓存的Value汇合变大，当高并接口申请时，会从Redis读取相干数据，每个申请读取的工夫变长，一直的叠加，导致呈现热点KEY状况，Redis某个分片处于阻塞，CPU使用率达到100%。

6、【案例】缓存热key

在Redis中，拜访频率高的key称为热点key，当某一热点key的申请到Server主机时，因为申请量特地大，导致主机资源有余，甚至宕机，影响失常的服务。

热key问题的产生，有如下两种起因：

  1. 用户生产的数据远大于生产的数据，比方热卖商品或秒杀商品、热点新闻、热点评论等，这些典型的读多写少的场景会产生热点问题。
  2. 申请分片集中，超过单Server的性能极限，比方 固定名称key，哈希落入一台Server，访问量极大的状况，超过Server极限时，就会导致热点Key问题的产生。

那么在理论业务中，如何辨认到热点key呢？

  1. 凭借业务教训，进行预估哪些是热key；
  2. 客户端统计收集，本地统计或者上报；
  3. 如果服务端有代理层，能够在代理层进行收集上报；

当咱们辨认到热key，如何解决热key问题？

  1. Redis集群扩容：减少分片正本，平衡读流量；
  2. 进一步对热key进行散列，比方将一个key备份为key1,key2……keyN，同样的数据N个备份，N个备份散布到不同分片，拜访时可随机拜访N个备份中的一个，进一步分担读流量。
  3. 应用二级缓存，即本地缓存。

当发现热key后，将热key对应数据首先加载到应用服务器本地缓存中，缩小对Redis的读申请。

五、Redis 标准

1、禁止应用非database 0

阐明：

Redis-standalone架构，禁止应用Redis中的其余database。

原由：

  • 为当前业务迁徙 Redis Cluster 放弃兼容性.
  • 多个 database 用 select 切换时，更耗费CPU资源。
  • 更易自动化运维治理，如 scan/dbsize 命令只用于当database。
  • 局部 Redis Clients 因线程平安问题，不反对单实例多 database。

2、Key设计规范

按业务性能命名key前缀，避免key抵触笼罩，举荐 用冒号分隔，例如，业务名:表名，如 live:rank:user:weekly:1:202003。

Key的长度小于30个字符，Key名字自身是String对象，Redis硬编码限度最大长度512MB。

在Redis缓存场景，举荐Key都设置TTL值，保障不应用的Key能被及时清理或淘汰。

Key设计时禁止蕴含特殊字符，如空格、换行、单双引号以及其余转义字符。

3、Value设计规范

单个Value大小必须管制10KB以内，单实例键个数过大，可能导致过期键的回收不及时。

set、hash、list等简单数据类型，要尽量升高数据结构中的元素个数，倡议个数不要超过1000。

4、关注命令工夫复杂度

举荐应用O(1)命令，如get scard等。

O(N)命令关注N的数量，如下命令须要对N值在业务层面做管制。

  • hgetall
  • lrange
  • smembers
  • zrange

例如：smember命令工夫复杂度为O(n)，当n继续减少时，会导致 Redis CPU 继续飙高，阻塞其余命令的执行；

5、Pipeline应用

阐明：

Pipeline是Redis批量提交的一种形式,也就是把多个命令操作建设一次连贯发给Redis去执行,会比循环的单次提交性能更优。

Redis客户端执行一条命令分4个过程：发送命令 -> 命令排队 ->命令执行 -> 返回后果。

罕用的mget、mset命令，无效节约RTT（命令执行往返工夫），但hgetall并没有mhgetall，是不反对批量操作的。此时，须要应用Pipeline命令

例如：直播中台我的项目中，须要同时查问主播日、周、月排行榜，应用PIPELINE一次提交多个命令，同时返回三个榜单数据。

6、线上禁用命令

  • 禁止应用Monitor

禁止生产环境应用monitor命令，monitor命令在高并发条件下，会存在内存暴增和影响Redis性能的隐患

  • 禁止应用Keys

keys操作是遍历所有的key，如果key十分多的状况下导致慢查问，会阻塞其余命令。所以禁止应用keys及keys pattern命令。

倡议线上应用scan命令代替keys命令。

  • 禁止应用Flushall、Flushdb

删除Redis中所有数据库中的所有记录，并且该命令是原子性的，不会终止执行，一旦执行，将不会执行失败。

  • 禁止应用Save

阻塞以后redis服务器，直到长久化操作实现为止，对于内存较大的实例会造成长时间的阻塞。

  • BGREWRITEAOF

手动AOF，手动长久化对于内存较大的实例会造成长时间的阻塞。

  • Config

Config是客户端配置形式，不利于Redis运维。倡议在Redis配置文件中设置。

六、Redis 监控

1、慢查问

办法一：slowlog获取慢查问日志

127.0.0.1:{port}> slowlog get 5

1) 1) (integer) 47

   2) (integer) 1533810300

   3) (integer) 175833

   4) 1) "DEL"

      2) "spring:session:expirations:1533810300000"

2) 1) (integer) 46

   2) (integer) 1533810300

   3) (integer) 117400

   4) 1) "SMEMBERS"

办法二：更全面的慢查问能够通过CacheCloud工具监控。

门路："利用列表"-点击相干利用名-点击"慢查问"Tab页。

点击"慢查问"，重点关注慢查问个数及相干命令。

2、监控Redis实例绑定的CPU外围使用率

因为Redis是单线程，重点监控Redis实例绑定的CPU外围使用率。

个别CPU资源使用率为10%左右，如果使用率高于20%时，思考是否应用了RDB长久化。

3、Redis分片负载平衡

以后redis-cluster架构模式，3个master和3个Slave组成的集群，关注 Redis-cluster每个分片requests流量平衡状况；

通过命令获取：redis-cli -p{port} -h{host} --stat

个别状况，超过12W须要告警。

4、关注大key BigKey

通过Redis提供的工具，redis-cli定时扫描相应Redis大Key，进行优化。

具体命令如下：redis-cli -h 127.0.0.1 -p {port} --bigkeys或 redis-memory-for-key -s {IP} -p {port} XXX_KEY

个别超过10K为大key，须要重点关注，倡议从业务层面优化。

5、监控Redis占用内存大小

Info memory 命令查看，防止在高并发场景下，因为调配的MaxMemory被耗尽，带来的性能问题。

重点关注 used_memory_human 配置项对应的value值，增量过高时，须要重点评估。

七、总结

联合具体业务个性，正当评估Redis所需内存容量、抉择数据类型、设置单key大小，能力更好地服务于业务，为业务提供高性能的保障。

作者：Jessica Chen