Redis备份持久化,内存回收策略

1 redis基础配置文件
在windows系统下默认的配置文件为redis.window.conf,linux下默认的配置文件为redis.conf

2 备份持久化
redis中的两种备份方式:快照,追加文件.Redis允许使用其中的一种,同时使用两种,或者两种都不用.
1)快照(snapshotting)
备份当前瞬间Redis在内存中的数据记录
优点:恢复重启速度比较快
缺点:如果当前Redis的数据量比较大,备份可能造成卡顿现象;
2)追加文件(Append-Only File AOF)
当redis执行写命令后,在一定的条件下将执行过的写命令一次保存在Redis中的文件中,数据缺失后就可以依次那些保存的命令来恢复数据了.
优点:由于只是追加写入,所以备份一般不会造成卡顿
缺点:恢复重启要执行更多的命令, 备份文件也可能很大.

redis默认的备份配置为:
save 900 1 // 当900秒执行一个写命令时,启用快照备份
save 300 10 //当300秒执行10个写命令时,启用快照备份
save 60 10000 //当60秒执行10000个写命令时,启用快照备份
stop-writes-on-bgsave-error yes //异步保存命令,系统将启动另一个线程把redis的数据保存到对应的数据文件.他和save命令最大的不同是他不会阻塞客户端的写入,也就是在执行bgsave的时候,允许客户端继续读写redis.在默认的情况下,如果redis在执行bgsave失败后,Redis将停止接收写操作,以这样一种强硬的方式让用户知道数据不能正确的持久化到硬盘,否则就会没人注意到灾难的发生,如果后台保存进程重新启动工作,Redis也将自动允许写操作.如果安装了靠谱的监控,不希望redis这样做,那么可以将其修改为no

rdbchecksum yes //是否对rdb文件进行检验,如果是则将对rdb文件进行检验.rdb文件指的是Redis持久化的数据文件
dbfilename dump.rdb //数据文件,使用快照模式备份时,Redis将使用它来保存数据,将来可以使用它来恢复数据
appendonly no //如果appendonly设置为no,则不启用AOF方式进行备份
appendfilename “appendonly.aof” //定义追加的写入文件为appendonly.aof,采用AOF追加文件时命令都会写到这里
appendfsync everysec //值有3个,always:执行Redis命令时,同时同步到AOF文件,这样会使redis同步刷新AOF文件,造成缓慢.everysec代表每秒同步一次命令到AOF文件.no:由客户端调用命令执行备份,Redis本身不备份文件.
no-appendfsync-on-rewrite no // 是否在后台AOF文件重写rewrite期间调用fsync,默认为no,标识要调用fsync(无论后台是否有子进程刷盘).redis在后台写RDB文件或重写AOF期间,会存在大量磁盘IO,因此在某些linux系统中,调用fsync可能会造成阻塞.
auto-aof-rewrite-percentage 100 //重写aof文件的条件,默认为100.表示与上次rewrite的AOF文件大小相比,当前AOF文件增长量超过上次AOF文件大小的100%时,就会触发backgroundrewrite.若配置为0,则会禁用自动rewrite.
auto-aof-rewrite-min-size 64mb //指定触发rewrite的AOF大小.若AOF文件小于该值,即使当前文件的增量比例达到auto-aof-rewrite-percentage的配置值,也不会自动rewrite.即这两个条件同时满足时,才会触发rewrite.
aof-load-truncated yes //redis在恢复时会忽略最后一条可能存在问题的指令,默认为yes

3 内存回收策略
volatile-lru:采用最近使用最少的淘汰策略,Redis将回收那些超时的(仅仅是超时的)键值对,也就是它只淘汰那些超时的键值对.
allkeys-lru:采用淘汰最少使用的策略,Redis将对所有的(不仅仅是超时的)键值对采用最近使用最少的淘汰策略
volatile-random:采用随机淘汰策略删除超时的(仅仅是超时的)键值对
allkeys-random:采用随机淘汰策略删除所有的键值对,包括没有超时的.
volatile-ttl:采用删除存活时间最短的键值对策略
noeviction:不淘汰任何键值对,当内存已满时,如果做读操作,它将正常工作,做写操作时,返回错误.

发布了98 篇原创文章 · 获赞 7 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/musi_m/article/details/100675579