redis官方给出的警告:当内存不足时,redis会根据配置的缓存策略淘汰部分keys,以保证写入成功。当无淘汰策略时或没有找到适合淘汰的key时,redis直接返回out of memory
错误。
最大缓存配置
在redis中,允许用户设置最大使用内存大小
maxmemory 512G
1.redis提供的数据淘汰策略
- volatile-lru: 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
- volatile-lfu:从已设置过期的keys中,删除一段时间内使用次数最少的
- volatile-ttl:从已设置过期时间的数据集中挑选最近将要过期的数据淘汰
- volatile-random: 从已设置过期时间的数据集中随机选择数据淘汰
- allkeys-lru:从数据集中挑选最近最少使用的数据淘汰
- allkeys-lfu:从所有keys中,删除一段时间内使用次数最少的
- allkeys-random:从数据集中随机选择数据淘汰
- no-enviction(驱逐):禁止驱逐数据(不采用任何淘汰策略,默认即为此配置),针对写操作,返回错误信息
在平时使用时应尽量主动设置/更新key的expire时间,主动删除不活跃的旧数据,有助于提升查询性能。
2.redis持久化
redis数据存放于内存,读取高效,但断电后数据会丢失,因此需要做持久化操作,使其数据及时同步到磁盘DB
常用方法:
1.RDB
RDB是redis的默认持久化机制。RDB相当于快照,保存的是一种状态。几十G数据 ->几KB快照;快照是默认的持久化方式,这种方式就是将内存中数据以快照的方式的写入到二进制文件中,默认的文件名为dump.rdb
优点:
- 快照保存数据极快、还原数据极快,适用于灾难备份
缺点:
- 小内存机器不适合使用,
快照条件:
- 服务器正常关闭时
- key满足一定条件,会进行快照
sava 900 1 //每900秒至少1个key发生变化,产生快照
sava 300 10 //每300秒至少10个key发生变化,产生快照
save 60 10000//每60秒至少10000个key发生变化,产生快照
2.AOF
由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉就会丢失最后一次快照的所有修改,如果应用要求不能丢失任何修改的话,可以采用aof持久化方式
Append-only file:aof比快照方式有更好的持久化性,是由于在使用aof持久化时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
有3种方式如下(默认是:每秒fsync一次)
- appendonly yes //启用aof持久化
- #appendfsync always //收到写命令就立即写入磁盘,最慢,但是保证完全的持久化
- appendfsync everysec //每秒钟写入磁盘一次,在性能和持久化方面做了最好的折中
- appendfsync no// 完全依赖os,性能最好,持久化没保证
产生的问题:
aof的方式也同时带来了另一个问题,持久化文件会变得越来越大,例如我们调用 incr test命令100次,文件中必须保存全部的100条命令,其实大部分都是多余的。