RDB和AOF
RDB:Redis DataBase
在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork出一个子进程,先将数据集写入临时文件,写入成功后,再替换之间的文件,用二进制压缩存储。
为了写快照而暂停写操作,这肯定是不能接受的。所以这个时候,Redis就会借助操作系统提供的写时复制(Copy-On-Write)技术,在执行写快照的同时,正常处理写操作。
简单来说,bgsave子进程由主线程fork生成的,可以共享主线程的所有内存数据。bgsave子进程运行后,开始读取主线程的内存数据,并把他们写入RDB文件。此时,如果主线程对这些操作也是读操作(例如途中的A操作),那么,主线程和bgsave子进程相互不会影响。但是,如果主线程要修改一块数据(例如途中的键值对C),那么,这块数据就会被复制一份,生成该数据副本。然后bgsave子进程会把这个副本写入到RDB文件,而在这个过程中,主线程任然可以直接修改原来的数据。
优点:
整个redis数据库将只包含一个文件 dump.rdb,方便持久化
容灾性好,方便备份
性能最大化,fork子进程来完成写操作,让主进程继续处理命令,所以是IO最大化,使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能。
相对于数据集大时,比AOF启动效率更高。
缺点
数据安全性低。RDB时间隔一段时间进行持久化,如果持久化之间redis发生故障,会发生数据丢失,所以这种方式更适合数据要求不严谨的时候
由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至时一秒钟。
AOF:Append Only File
以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录。记录的是写后日志,因为redis没有语法检查功能,所以只能通过执行来判断是否正确。
三种同步策略
Always,同步写回:每个写命令执行完,立即同步地将日志写回磁盘
Everysec:每秒写回:每个写命令执行完,只是先把日志写到AOF文件的内存缓存区,每隔一秒把缓冲区中的内容写入磁盘。
No,操作系统控制写回:每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。
AOF重写
和AOF日志由主线程写回不同,重写过程是由后台子进程bgrewriteaof来完成的,这也是为了避免阻塞主线程,导致数据库性能下降。
重写过程可以总结为 一个拷贝,两处日志
一个拷贝就是指,每次执行重写时,主线程fork出后台的bgrewriteaof子进程。此时fork会把主线程的内存拷贝一份给bgrewriteaof子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,计入重写日志。
两处日志又是什么呢?
因为主线程未阻塞,仍然可以处理新来的操作。此时,如果有写操作,第一次日志就是指正在使用的AOF日志,Redis会把这个操作写到它的缓冲区。这样一来,即使宕机了,这个AOF日志的操作仍然是齐全的,可以用于恢复。
而第二个日志,就是指新的AOF重做日志了。这个操作也会被记录到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的AOF文件,以保证数据库最新状态的记录。此时就可以使用新的AOF文件代替旧文件。
优点
数据安全,redis采用三种同步策略,即每秒同步、每修改同步和操作系统控制同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,一旦系统出现宕机,那么丢失的也仅仅是这一秒的数据。而每修改同步,可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。
通过append模式写文件,即使中途服务器宕机也不会破坏已经存在的内容,可以通过redis-check-aof工具解决数据一致性问题。
AOF机制的rewrite模式。定期对AOF文件进行重写,达到压缩的目的。
缺点
AOF比RDB文件大,且恢复速度慢
数据集大的时候,比RDB启动效率低
运行效率没有RDB高
AOF文件比RDB更新频率高,优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配置了,优先加载AOF