Redis的持久化机制
Redis的持久化机制有什么作用
Redis在运行时是把数据存在运行内存中的,一旦服务器宕机,这些数据就会丢失.
持久化就是把内存中的数据保存在磁盘中,这样下次启动时,可以恢复保存在磁盘中的数据到内存中,这样就使Redis数据库保持了健壮性.
Redis的持久化方式有哪些
RDB
Redis的默认持久化方式是RDB方式.按照一定的时间周期策略把内存中的数据已快照的形式保存成二进制文件到磁盘上.对应的文件名叫dump.rdb,配置文件中的save参数来配置快照的周期.
优势:
- RDB文件紧凑,全量备份,非常适合用于进行备份和灾难恢复。
- 生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势:
RDB快照是一次全量备份,存储的是内存数据的二进制序列化形式,存储上非常紧凑。当进行快照持久化时,会开启一个子进程专门负责快照持久化,子进程会拥有父进程的内存数据,父进程修改内存子进程不会反应出来,所以在快照持久化期间修改的数据不会被保存,可能丢失数据。
AOF
Redis会把每一个收到的命令都通过write函数追加到文件末尾,类似于MySQL的binlog.当Redis重启时会重新执行文件中保存的写命令,在内存中重建数据库的数据.当RDB和AOF同事开启时,Redis会优先选择AOF恢复.
优点:
- AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。
- AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
- AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
- AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令给删了,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据
缺点:
- 对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大.
- AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的.
- 以前AOF发生过bug,就是通过AOF记录的日志,进行数据恢复的时候,没有恢复一模一样的数据出来.
对比
命令 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
轻重 | 重 | 轻 |