上篇文章介绍了redis缓存设计,热点key,bigkey注意事项。
原创 redis缓存设计-Redis(七)https://blog.csdn.net/ke1ying/article/details/131268967
- hgetall,lrange,smembers,zrange,sinter等并非不能使用,要指定明确的值,遍历的话要使用hscan、sscan、zscan代替。
- 禁止使用keys,flushall,flushdb等,通过rename禁止掉,或者用scan方式渐进。
- 合理的使用select:
redis多DB较弱,而且如果每个都有很大的高并发访问,而都接入一个redis,效率是底下且会造成干扰。(不想干的业务进行拆分,不共用)
前者是非原生的,后者是原生的,原生有原子性,非原生没有,pipeline可以打包不同命令,并且他需要客户端服务端都支持。
一般maxTotal*nodes 小于 maxclients
为什么呢?
因为如果每个客户端处理的是1000,而我们有10个客户端,那么可以处理10000,即使maxclients设计的再大,剩余的也不会存储。
那么根据每个客户处理1000,则需要配置50个客户端就可以完成QPS5000的业务,但实际要考虑一些网络消耗时间,所以实际要比这个值稍微大一点。
但又不是越大越好,占用太多服务器和客户端资源,而且如果有一个大的阻塞key,对于配置再多也无济于事。
当redis在业务峰值期间连接了几十个redis连接,这时候峰值过后,redis会慢慢关闭连接,留下maxIdle空闲连接数,正常配置默认都是maxIdle。
连接池预热,当redis刚启动的时候,就有大量并发访问,这时候可以采用ping命令先连接redis,保证先有空闲连接数。(预热的时候千万别执行jedis.close)
当我们并发量很高,或者并发量很频繁的时候,maxIdle和maxTotal设置可以保持一致,这样避免连接创建和关闭造成的性能损耗,并发量不是特别高就没必要。
这种情况下会出现一个问题是冷数据无法及时清理,如果一个数据不被访问了,不是一直不会被删除吗。
- volitile-ttl:在筛选时候,会针对过期时间,越早过期的先删除。
- Volitile-random:对设置过期的key,随机删除。
- Volatile-lru:采用lru算法对过期key删除。
- Volatile-lfu:采用lfu算法对过期key删除。
针对所有key
不删除
Lru算法:用最近一次访问时间作为参考,淘汰很久时间之前访问的数据。
热点数据如果用lru算法,效率可能会更高,但如果是偶发、周期性的批量操作导致LRU命中率急剧下降,缓存污染比较严重,这时候LFU更好。
(比如热点数据访问100次,但是冷数据访问就2次,但因为是按访问时间来淘汰的,所以这时候可能会把热点数据淘汰,所以这时候采用lfu更好)
默认推荐用lru算法,maxmemory–policy默认是noeviction。这里maxmemory一定要设置,如果不设置,redis超过物理内存限制,内存数据和磁盘会频繁swap,会导致性能下降。
对于主从节点,主节点是策略删除,从节点是被同步的del key删除。
原文地址:https://blog.csdn.net/ke1ying/article/details/131296237
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_33282.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!