redis缓存设计-Redis（八）

上篇文章介绍了redis缓存设计，热点key，bigkey注意事项。

redis缓存设计-Redis（七）

一、命令使用

1、hgetall，lrange，smembers，zrange，sinter等并非不能使用，要指定明确的值，遍历的话要使用hscan、sscan、zscan代替。

2、禁止使用keys，flushall，flushdb等，通过rename禁止掉，或者用scan方式渐进。

3、合理的使用select：

redis多DB较弱，而且如果每个都有很大的高并发访问，而都接入一个redis，效率是底下且会造成干扰。（不想干的业务进行拆分，不共用）

4、可以采用pipeline代替mget，mset：

前者是非原生的，后者是原生的，原生有原子性，非原生没有，pipeline可以打包不同命令，并且他需要客户端服务端都支持。

5、redis事务比较弱建议用lua脚本实现。

​

二、核心参数

1、maxTotal

最大连接数，早期较maxActive

一般maxTotal*nodes 小于 maxclients

为什么呢？

因为如果每个客户端处理的是1000，而我们有10个客户端，那么可以处理10000，即使maxclients设计的再大，剩余的也不会存储。

如果我们要求业务QPS是50000？

那么根据每个客户处理1000，则需要配置50个客户端就可以完成QPS5000的业务，但实际要考虑一些网络消耗时间，所以实际要比这个值稍微大一点。

但又不是越大越好，占用太多服务器和客户端资源，而且如果有一个大的阻塞key，对于配置再多也无济于事。

2、maxIdle和minIdle

最大空闲连接 和 最小空闲连接

当redis在业务峰值期间连接了几十个redis连接，这时候峰值过后，redis会慢慢关闭连接，留下maxIdle空闲连接数，正常配置默认都是maxIdle。

连接池预热，当redis刚启动的时候，就有大量并发访问，这时候可以采用ping命令先连接redis，保证先有空闲连接数。（预热的时候千万别执行jedis.close）

当我们并发量很高，或者并发量很频繁的时候，maxIdle和maxTotal设置可以保持一致，这样避免连接创建和关闭造成的性能损耗，并发量不是特别高就没必要。

三、redis删除策略

删除分为 被动删除 和 主动删除。

1、被动删除：又叫惰性删除，当我们删除一个key的时候不会立马删掉，会在下一次访问的时候，触发惰性删除策略。（获取前判断key是否过期，过期则删除返回null）

这种情况下会出现一个问题是冷数据无法及时清理，如果一个数据不被访问了，不是一直不会被删除吗。

2、主动删除：所以redis会定期清理一些已过期的key。

3、当已用内存超过maxmemory时，触发主动删除策略。

主动删除策略在4.0之前有6种，redis4.0之后8种。

针对过期key：

1）volitile-ttl：在筛选时候，会针对过期时间，越早过期的先删除。

2）Volitile-random：对设置过期的key，随机删除。

3）Volatile-lru：采用lru算法对过期key删除。

4）Volatile-lfu：采用lfu算法对过期key删除。

针对所有key

5）allkeys-random：对所有key随机删除。

6）Allkeys-lru：lru算法对所有key进行删除。

7）Allkeys-lfu：lfu算法对所有key进行删除。

不删除

8）noeviction：不删除任何数据，提示OOM，这时候redis只支持读数据。

Lru算法：用最近一次访问时间作为参考，淘汰很久时间之前访问的数据。

Lfu算法：以访问次数参考，淘汰次数少的数据。

热点数据如果用lru算法，效率可能会更高，但如果是偶发、周期性的批量操作导致LRU命中率急剧下降，缓存污染比较严重，这时候LFU更好。

（比如热点数据访问100次，但是冷数据访问就2次，但因为是按访问时间来淘汰的，所以这时候可能会把热点数据淘汰，所以这时候采用lfu更好）

默认推荐用lru算法，maxmemory-policy默认是noeviction。这里maxmemory一定要设置，如果不设置，redis超过物理内存限制，内存数据和磁盘会频繁swap，会导致性能下降。

对于主从节点，主节点是策略删除，从节点是被同步的del key删除。