Redis持久化RDB和AOF
为什么Redis需要持久化?
因为Redis属于内存型数据库,数据是储存在内存当中的,当遇到不可抗力因素,比如断电,那么储存在内存中的数据就会丢失。所以为了保证数据的完整性,我们需要做持久化操作,来保证数据的完整性。
Redis中都有哪些持久化机制?
Redis早就考虑到了这一点,所以在Redis中,为我们准备了两种持久化的机制,RDB和AOF。
既然Redis为我们提供了两种持久化的机制,那我们到底该选用哪个呢?其实啊,在Redis配置文件中RDB这种机制是默认开启的,而AOF机制是默认关闭的,也就是说如果你不进行配置,那么Redis就默认你使用了RDB这种持久化的机制。而当你开启AOF机制,那么Redis就会优先使用AOF持久化机制来进行数据的持久化操作。
下面我们来了解一下什么是RDB,什么又是AOF。
RDB(Redis Database):
RDB是Redis用来持久化的一种机制,是把当前内存中的数据集快照写进磁盘中。
在上篇博客中提到过,在redis.conf配置文件中有一个叫做SNAPSHOTTING的配置模块,在里面我们可以看到有save 900 1 ,save 300 10 , save 60 10000。这里的save配置的是触发持久化操作的条件,save 900 1就是指在900秒内至少有一个key发生了改变,那么我就执行持久化操作,同理save 300 10 , save 60 10000也是指在300秒/60秒内有至少10/10000个key发生了改变就进行持久化操作。
当目前的数据修改达到我们配置的save条件之后,Redis就会将内存中的数据保存在dump.rdb(默认是dump.rdb,当然这个也可以在配置文件中进行更改)中。当Redis突然宕机重新启动的时候,Redis会读取dump.rdb文件中的数据加载到内存当中,很好的保证了数据的完整性。
RDB优点:
- RDB在执行写操作时是通过从主进程里fork的子进程进行的写入的,能够很好的保证Redis的性能不会受到太大影响。
- 和AOF机制相比,RDB是通过dump.rdb文件来进行恢复数据的,效率更佳。
RDB缺点:
- 即使配置了save 1 1也有可能在1秒之内发生了突发事件导致服务崩溃,进而丢失那一秒钟的数据,适合对数据完整性要求不高的情况下开启此机制。
AOF(Append Only File):
Redis是默认关闭AOF机制的,他是通过记录我们操作的命令来达到数据持久化操作的目的的。
我们可以在配置文件中把他打开appendonly yes(开启AOF机制)
AOF会把我们执行的命令一条一条追加到文件中的,那么可想而知,随着命令越来越多,那么保存的文件就会越来越大,当文件达到我们配置的一个空间的时候,Redis就会通过BGREWRITEAOF命令来对AOF日志文件进行重写。
auto-aof-rewrite-percentage 100 #AOF文件大小超过上次重写时文件大小的百分之几开始重写,如果之前没有写过,则根据启动时文件大小。
auto-aof-rewrite-min-size 64mb #允许重写的最小占用空间
同步策略可以通过以下进行配置:
appendfsync always #当有命令执行时就同步到AOF文件中
appendfsync everysec #每隔1秒同步一次
appendfsync no #不同步
当AOF和RDB同时开启时Redis是如何决定使用哪种机制的呢?
Redis启动时会读取配置文件,先去检查AOF是否开启,如果开启则加载AOF文件到内存中并启动成功,若AOF没有开启,则去加载RDB文件到内存中并启动成功。
AOF优点:
- AOF文件通过追加的方式写入,所以不用进行内存寻址,写入效率高。
- AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。因为在rewritelog的时候,会对其中的指导进行压缩,创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候,老的日志文件还是照常写入。当新的merge后的日志文件ready的时候,再交换新老日志文件即可。
AOF缺点:
- 同RDB一样,当设置AOF同步策略为everysec时,最多也是每秒执行一次同步,有可能会丢失一秒的数据,但当同步策略设置为always虽然能防止数据的丢失,同时也付出了性能的代价,二则不可兼得。
- 对于相同的数据,AOF文件比RDB文件更占用空间。
来源:oschina
链接:https://my.oschina.net/u/4257499/blog/4489867