Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案

Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案

Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第1张图片

Redis的高性能是由于其将所有数据都存储在了内存中,为了使Redis在重启之后仍能保证数据不丢失,需要将数据从内存中同步到硬盘中,这一过程就是持久化。
Redis支持两种方式的持久化,一种是RDB方式,一种是AOF方式。可以单独使用其中一种或将二者结合使用。

RDB持久化(默认支持,无需配置)

该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

AOF持久化

该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。

无持久化

我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的Memcached(一个自由开源的,高性能,分布式内存对象缓存系统)了。

1、RDB持久化

Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第2张图片

1.1、RDB持久化机制优点

一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,让redis的数据存取速度变快,这对于文件备份而言是非常完美的。

1.2、RDB持久化机制缺点

1.如果想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失,服务器断电时会丢失部分数据(数据的完整性得不到保证)。
2.由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

1.3、快照与备份

快照是数据存储的某一时刻的状态记录。

备份则是数据存储的某一个时刻的副本。

1.4、快照触发条件

1.客户端执行命令save和bgsave会生成快照;
2.根据配置文件save m n规则进行自动快照;
3.主从复制时,从库全量复制同步主库数据,此时主库会执行bgsave命令进行快照;
4.客户端执行数据库清空命令FLUSHALL时候,触发快照;
5.客户端执行shutdown关闭redis时,触发快照;

1.5、RDB持久化机制的配置

# 如果900s内,如果至少有一个1个key进行了修改,就进行持久化操作 
save 900 1 
# 如果300s内,如果至少10个key进行了修改,就进行持久化操作 
save 300 10 
# 如果60s内,如果至少10000个key进行了修改,就进行持久化操作 
save 60 10000 
# 关闭该规则使用save “ ” 
 
# yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。
stop-writes-on-bgsave-error yes   
# # 是否压缩 rdb 文件,需要消耗一些cpu资源,该功能可以节约磁盘空间。
rdbcompression yes                
# 在写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动
rdbchecksum yes
# 持久化文件名
dbfilename dump.rdb       
# 数据文件存放目录,rdb快照文件和aof文件都会存放至该目录,请确保有写权限        
dir ./      

1.6、测试

1、删除redis安装目录下的dump.rdb文件
2、对redis进行操作,比如set test abc
3、关闭服务端并观察bin目录的变化(会发现重新出现dump.rdb文件)

2、AOF持久化

Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第3张图片
当redis存储非临时数据时,为了降低redis故障而引起的数据丢失,redis提供了AOF(Append Only File)持久化,从单词意思讲, 将命令追加到文件。AOF可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中
在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作,redis都会记录到文件中,所以开启AOF持久化会对性能有一定的影响

以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件 但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件 的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF持久化数据丢失更少,其消耗内存更少(RDB方式执行bgsave会有内存拷贝)

2.1、开启AOF持久化

默认情况下,redis是关闭了AOF持久化,开启AOF通过将redis.windows.conf配置文件中的appendonly改为yes开启。将appendonly修改为yes,开启aof持久化机制,默认会在目录下产生一个appendonly.aof文件。修改redis.windows.conf配置文件或者在命令行直接使用config set修改,再用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis,AOF持久化直接生效。
config get appendonly 查询配置状态
config set appendonly yes 修改配置,命令生效了,但配置文件里没有生效
Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第4张图片
config rewrite 写入到redis.conf中,配置文件生效(如果先将该配置文件中改为了yes则只需要通过config set appendonly yes 命令改为yes即可,平常不想用即改为no即可)
Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第5张图片

2.2、AOF配置

appendonly no   # 默认是不开启aof模式的,默认使用rdb方式进行持久化,大部分情况rdb够用
appendfsync always       # 每执行一次更新命令,持久化一次
appendfsync everysec     # 每秒钟持久化一次
appendfsync no           # 不持久化

2.3、AOF文件错误

如果这个 aof 文件有错误,这时候 redis 是启动不起来的,我们需要修复这个aof文件 redis 给我们提供了一个工具 redis-check-aof --fix 。

redis-check-aof --fix appendonly.aof

这个工具可以修复错误,但是可能会造成一部分数据丢失(出现错误的那部分数据)。

2.4、AOF重写规则

aof 默认就是文件的无限追加,文件会越来越大。
Redis - redis.windows.conf配置文件及RDB和AOF数据持久化方案_第6张图片
如果 aof 文件大于 64m,太大了。 fork一个新的进程来将我们的文件进行重写。

2.5、优点

每一次修改都同步,文件的完整会更加好,持久化良好,能包证数据的完整性

2.6、缺点

1、相对于数据文件来说,aof远远大于 rdb,修复的速度也比 rdb慢。

2、Aof 运行效率也要比 rdb 慢,所以我们redis默认的配置就是rdb持久化。

2.7、测试

1、删除appendonly.aof
2、设置appendonly为yes
2、对redis进行操作,比如向redis中存入一个key
3、观察bin目录的变化(appendonly.aof文件会重新出现,打开后里面内容是刚才对redis操作的语句)

3、RDB-AOF混合持久化

通过aof-use-rdb-preamble配置参数控制,yes则表示开启,no表示禁用,默认是禁用的,可通过config set修改。

4、持久化扩展

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储。

2、AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始 的数据,AOF命令以Redis 协议追加保存每次写的操作到文件末尾,Redis还能对AOF文件进行后台重 写,使得AOF文件的体积不至于过大。

3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化。

4、同时开启两种持久化方式

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。

RDB 的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有 AOF可能潜在的Bug,留着作为一个万一的手段。

5、性能建议

因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够 了,只保留 save 900 1 这条规则。

如果Enable AOF ,好处是在恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自 己的AOF文件就可以了,代价一是带来了持续的IO,二是AOF rewrite 的后将 rewrite 过程中产 生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite 的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重 写可以改到适当的数值。

如果不Enable AOF ,仅靠 Master-Slave Repllcation 实现高可用性也可以,能省掉一大笔IO,也 减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几分钟的数据, 启动脚本也要比较两个 Master/Slave 中的 RDB文件,载入较新的那个,微博就是这种架构。

你可能感兴趣的:(JAVA全栈学习路线,#,java,ee,redis,windows,数据库,java,后端,缓存)