文章目录
- 1.redis键值设计
- 2. 命令使用优化
- 3. redis连接池配置参数设计
- 4. redis连接池预热
- 5. redis的key过期删除策略
- 6. 秒杀场景下redis性能提升策略
1.redis键值设计 redis合理的键值设计,可以增加可读性和可管理性,特别在大型项目中,要特别注意!
①:key设计规范
- 【建议】: 可读性和可管理性 以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id
//表示交易系统中的订单号
1 trade:order:1
- 【建议】:简洁性 保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:
// 表示某用户的朋友发来的消息
user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}
- 【强制】:不要包含特殊字符
反例:包含空格、换行、单双引号以及其他转义字符
②:value设计规范
(1)【强制】:拒绝bigkey(防止网卡流量、慢查询)
什么是bigkey?
在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)可以存 储大约40亿个(2^32-1)个元素,这么大的存储空间,为bigkey的产生创造了条件。如果有以下情况,就认为是bigkey!
①:字符串类型:它的big体现在单个value值很大,一般认为超过10KB就是bigkey。
②:非字符串类型:哈希、列表、集合、有序集合,它们的big体现在元素个数太多。 一般来说,string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。
bigkey是如何产生的?
在一般来说,bigkey的产生都是由于程序设计不当,或者对于数据规模预料不清楚造成的,比如:
①:社交类:粉丝列表,如果某些明星或者大v不精心设计下,必是bigkey
②:统计类:例如按天存储某项功能或者网站的用户集合,除非没几个人用,否则必是bigkey。
③:缓存类:将数据从数据库load出来序列化放到Redis里。注意缓存必要字段即可!
bigkey的危害是什么?
- 导致redis阻塞
由于redis操作命令是单线程的,当bigkey太大时,操作bigkey耗时过长,其他命令都会被阻塞!
- 网络拥塞
bigkey也就意味着每次获取要产生的网络流量较大,假设一个bigkey为1MB,客户端每秒访问量为1000,那么每秒产生1000MB的流量,对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾,而且一般服务器会采用单机多实例的方式来部署,也就是说一个bigkey可能会对其他实例也造成影响,其后果不堪设想。
- 过期删除
有个bigkey,它安分守己(只执行简单的命令,例如hget、lpop、zscore等),但它设置了过期时间,当它过期后,会被删除,如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes),就会存在阻塞Redis的可能性。
如何优化bigkey?
- 拆
比如一个bigkey,存储了100w的用户数据,那么可以把这个key拆分成200个key,每个key下存储5000个用户数据
- 避免使用hgetAll全量获取
如果bigkey不可避免,也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要 hmget,而不是hgetall),删除也是一样,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,尽量使用优雅的方式来处理。
(2)【推荐】:选择适合的数据类型。
场景:存储某个用户(要合理控制和使用数据结构,但也要注意节省内存和性能之间的平衡)
正例:使用hash结构hmset user:1 name tom age 19 favor football 反例:使用string结构set user:1:name tom
set user:1:age 19
set user:1:favor football (3) 【推荐】:控制key的生命周期,redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期)。
注意:redis内部默认有16个数据库,在微服务场景下,不要用redis的数据库做业务数据区分,比如订单放1库,商品放2库,这样做毫无作用,因为这些库都是一个redis服务,在高并发场景下,虽然访问的时不同的库,但redis还是单线程执行的!!
2. 命令使用优化 1.【推荐】 使用命令时关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】:禁用命令
禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的方式渐进式处理。
3.【推荐】合理使用redis数据库
redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。
4.【推荐】使用批量操作提高效率原生命令:例如mget、mset。
非原生命令:可以使用pipeline提高效率。 但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。
注意两者不同:
- 原生命令是原子操作,pipeline是非原子操作。
- pipeline可以打包不同的命令,原生命令做不到
- pipeline需要客户端和服务端同时支持。
5.【建议】Redis事务功能较弱,不建议过多使用,可以用lua替代
3. redis连接池配置参数设计 redis连接池参数如下:
参数含义默认值使用建议maxTotal资源池中最大连接数8设置建议见下文maxIdle资源池允许最大空闲的连接数8设置建议见下文minIdle资源池确保最少空闲的连接数0设置建议见下文blockWhenExhausted当资源池用尽后,调用者是否要等待。只有当为true时,下面的maxWaitMillis才会生效true建议使用默认值maxWaitMillis当资源池连接用尽后,调用者的最大等待时间(单位为毫秒)-1:表示永不超时不建议使用默认值testOnBorrow向资源池借用连接时是否做连接有效性检测(ping),无效连接会被移除false业务量很大时候建议设置为false(多一次ping的开销)。testOnReturn向资源池归还连接时是否做连接有效性检测(ping),无效连接会被移除false业务量很大时候建议设置为false(多一次ping的开销)。jmxEnabled是否开启jmx监控,可用于监控true建议开启,但应用本身也要开启 优化建议:
①:maxtotal:连接池最大连接数,早期版本叫maxActive!
对于maxtotal的优化要考虑很多因素:
- 业务希望的redis并发量(QPS)
- 命令执行时间
- 小于redis允许最大连接数
例如: nodes(例如应用个数) * maxTotal 是不能超过redis的最大连接数maxclients。
用一个例子说明
假如:
1.业务希望的QPS(每秒并发量)是50000
2.通过压测工具测得一次命令执行(拿连接+执行命令+归还连接)平均耗时为1ms,算得一个连接的QPS(每秒并发量)是1000
结论:
那么理论上需要的资源池大小是50000 / 1000 = 50个。但事实上这是个理论值,还要考虑到要比理论值预留一些资源,通常来讲maxTotal可以比理论值大一些,比如60个。但这个值不是越大越好,连接太多会一方面占用客户端和服务端资源,另一方面对于Redis这种高QPS的服务器,一个大命令的阻塞即使设置再大资源池仍然会无济于事。
②:maxIdle:业务需要的最大连接数
maxTotal是为了给出余量,而maxIdle才是业务需要的最大连接数,所以maxIdle不要设置过小,如果设置与maxTotal差距过大,则会有new Jedis(新建连接)开销。
一般推荐maxIdle可以设置为按上面的业务期望QPS计算出来的理论连接数50个,这样就避免连接池伸缩带来的性能干扰,maxTotal可以再放大一些,为redis预留一些资源!
③:minIdle(最小空闲连接数)
minIdle是至少需要保持的空闲的连接数。
注意:redis连接池是懒加载的,一开始不会有任何连接,用一个连接连接池帮我们生成一个连接,连接数量根据并发量增加,redis默认取maxIdle配置的连接数量。
比如 minIdle = 10 ;maxIdle = 20 ;maxtotal = 40。随着并发量逐渐增加,连接数量逐渐变大,但不会超过40,一段时间后,并发量下降,由于redis默认取maxIdle配置的连接数量20,所以超出20的连接会被释放,池中稳定存在20个连接,在这里minIdle配置显得无意义,可以通过配置修改minIdle为redispool默认连接数。
在并发非常高的情况下,为了保持redis最佳性能,可以配置maxTotal = maxIdle
4. redis连接池预热 由于redis连接池初始化时不会有连接,当系统启动时,突然爆发大量请求要获取redis数据,这样在短时间内会创建大量连接,影响系统性能,为了避免出现这种情况,可以给redis连接池做预热!
比如在系统启动时创建一些redis连接,执行简单命令,类似ping(),快速的将连接池里的空闲连接提升到minIdle的数量。注意执行ping()时不能立即把连接放回连接池,不然连接池只会有一个连接!
预热代码如下:List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());
//拿到minIdle得数量
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
Jedis jedis = null;
try {
jedis = pool.getResource();
minIdleJedisList.add(jedis);
//ping建立连接
jedis.ping();
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
//注意,这里不能马上close将连接还回连接池,否则最后连接池里只会建立1个连接。。
//jedis.close();
}
}
//统一将预热的连接还回连接池
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
Jedis jedis = null;
try {
jedis = minIdleJedisList.get(i);
//将连接归还回连接池
jedis.close();
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
}
} 5. redis的key过期删除策略 redis对于设置了过期时间,且已过期的key有三种清除策略:
- ①:惰性删除
当key过期时,不会立即删除,而是等到下一次读/写这个key时,才会先执行删除,再读/写,这也被称为惰性删除。缺点是如果后续一直不访问这个key,那么它会一直留在redis中,占用不必要的内存空间,对内存不友好
- ②:定时删除
为每个键设置一个定时器,一旦过期时间到了,则将键删除。这种策略对内存很友好,但是对 CPU 不友好,因为每个定时器都会占用一定的 CPU 资源。
- ③:定期扫描
系统每隔一段时间就定期扫描一次,发现过期的键就进行删除。不过 Redis 的定期扫描只会扫描设置了过期时间的键,因为设置了过期时间的键 Redis 会单独存储,所以不会出现扫描所有键的情况。这种策略相对来说是上面两种策略的折中方案
如果reids中所有的key都没有过期,而且此时内存满了,那么客户端继续执行 set 等命令时 Redis 会怎么处理呢?Redis 当中提供了不同的内存淘汰策略来处理这种场景。在Redis 4.0 之前一共实现了 6 种内存淘汰策略,可通过maxmemory-policy(默认是noeviction)来配置!在 4.0 之后,又增加了 2 种策略,总共8种如下:
a) 针对设置了过期时间的key做处理:
- volatile-ttl:在筛选时,会针对设置了过期时间的键值对,根据过期时间的先后进行删除,越早过期的越先被删除。
- volatile-random:就像它的名称一样,在设置了过期时间的键值对中,进行随机删除。
- volatile-lru:会使用 LRU 算法筛选设置了过期时间的键值对删除。
- volatile-lfu:会使用 LFU 算法筛选设置了过期时间的键值对删除。
b) 针对所有的key做处理:
- allkeys-random:从所有键值对中随机选择并删除数据。
- allkeys-lru:使用 LRU 算法在所有数据中进行筛选删除。
- allkeys-lfu:使用 LFU 算法在所有数据中进行筛选删除。
c) 不处理:
- noeviction:不会剔除任何数据,拒绝所有写入操作并返回客户端错误信息"(error) OOM command not
allowed when used memory",此时Redis只响应读操作。redis默认操作
LRU 算法(Least Recently Used,最近最少使用)
- 传统的LRU算法目的是:淘汰很久没被访问过的数据。在 Redis 当中,并没有采用传统的 LRU 算法,因为传统的 LRU 算法存在 2 个问题:
- 需要额外的空间进行存储。
- 可能存在某些 key 值使用很频繁,但是最近没被使用,从而被 LRU 算法删除。
为了避免以上 2 个问题,Redis 当中对传统的 LRU 算法进行了改造,通过抽样的方式进行删除。配置文件中提供了一个属性 maxmemory_samples 5,默认值就是 5,表示随机抽取 5 个 key 值,然后对这 5 个 key 值按照 LRU 算法进行删除,所以很明显,key 值越大,删除的准确度越高。
LFU 算法(Least Frequently Used,最近最少频率使用)
- 淘汰最近一段时间被访问次数最少的数据,以次数作为参考。热点数据通常用LFU算法!以次数为准
以上8中清除策略,应根据自身业务类型,配置好maxmemory-policy(默认是noeviction),推荐使用volatile-lru。如果不设置最大内存,当 Redis 内存超出物理内存限制时,内存的数据会开始和磁盘产生频繁的交换 (swap),会让 Redis 的性能急剧下降。
注意:当Redis运行在主从模式时,只有主节点才会执行过期删除策略,然后把删除操作”del key”同步到从结点删除数据。
6. 秒杀场景下redis性能提升策略 ①:多商品抢购场景下,可以加redis服务器。如果是大促场景下,有很多商品待抢购,由于不同的商品id通过槽位分布在不同的redis集群节点上,可以通过增加redis服务器来分散槽位分配,实现高可用的redis架构!
②:单商品秒杀场景下,增加redis服务器已无法起到优化作用,因为一个商品只能被分配到某一个redis集群节点中,秒杀这个商品会对当前redis节点产生较大压力!可以使用分段库存锁的思路来解决!
比如要秒杀id为001号商品,库存有1000个,可以把001拆分成001-1、001-2、001-3 … 001-10共拆分成10个小id来表示001号商品,每一个小id存储100库存,通过分段锁把单商品抢购优化为多商品抢购!这样在set key设置商品时由于hash(key)%16384得到的槽位不同,这些商品就被分配到不同的集群节点上,在抢购时判断001-1上是否还有库存,如果没有去其他节点减库存,这样就非常巧妙的实现了水平扩容,增强了系统性能!
|