Redis的持久化

Redis的数据都是存放在内存当中的，假如有一天Redis宕机了，那么数据将会全部丢失了。所以需要有一种机制来解决这种问题，Redis提供了持久化的机制。一种是RDB(Redis默认的），另一种是AOF。

RDB:在指定的时间间隔内，将数据写入到硬盘中。

RDB的原理：

大家都知道Redis是单线程的，如果这个线程既要相响应客户端的服务，又要进行内存快照，而内存快照的操作涉及到磁盘IO，相当影响系统的性能。那么怎么办呢？Redis使用了操作系统的COW，也就是Copy On Write机制，fork出一个子进程，父进程继续响应客户端的服务，而子进程来做快照持久化的操作。此时子进程和父进程共享数据段和代码段。子进程做持久化时不会数据，只是做一次遍历，将数据序列化到磁盘中。子进程会将数据写入到一个临时文件中，等到持久化结束了再将临时文件替换上一次持久化的文件。父进程可以随时接受请求，修改数据。但是父进程会将需要修改的页面的数据复制一个副本，对副本进行修改，而子进程的页面是没有变化的。

 

如何触发RDB持久化呢？

在redis.conf里面有：

save  900 1    #也就是说900秒内有1个key发生变化则做持久化，下面同理

save  300 10

save  60   10000

 

RDB方式的有点显而易见：

创建子进程，父进程不会被阻塞，最大化性能。

做大规模的数据进行恢复的时候，速度比AOF要快。

 

但是也会有缺点：

文件的完整性不好，可能会丢失数据。

 

下面介绍的是第二种持久化的方式AOF：

Redis的默认持久化的方式是RDB，所以要使用AOF的方式需要在redis.conf中开启    appendonly  true

AOF: 以日志的形式记录写的操作，将每个写操作的指令都记录下来，只追加不修改文件。

在Redis运行的过程中，aof文件会越来越大，而重放整个aof文件会非常耗时，所以要对aof文件进行瘦身。这时就需要使用到重写机制。

AOF重写：

可以使用bgrewriteaof指令来进行重写，原理是：

fork出一个新的子进程，将数据集转换成指令的集合序列化到一个新的aof文件中，序列化完毕后再将序列化过程中增量aof日志也追加到新的aof文件中，最后将新的aof文件去替换旧的aof文件。完成瘦身。

 

AOF日志是以文件的形式保存的，当对AOF文件进行追加操作的时候实际上就是将内容写入到一个内存缓存中，再从缓冲区中将脏数据异步刷到磁盘中。那么就会产生一个问题，如果数据还没来得及从缓存中刷到磁盘中，此时宕机了，那么数据就丢失了啊 ？ 那怎么办？

可以使用的是Linux的glibc的fsync(int fd)函数来将内容强制直接从内存刷到磁盘中。这样就可以保证数据的不丢失了。但是这将是一个非常耗时的操作。

生产环境下Redis会每隔一秒钟fsync一次，在安全和性能之间做一个折中。这个是可以自己配置的。

另外还有两种：永不fsync，让操作系统去决定什么时候同步磁盘，很不安全。另外就是每执行一条命令就fsync一次，性能非常差.。

 

可以看出AOF优点还是明显的：

在数据的完整性方面做单比RDB方式要好。

提供了多种持久化的方法，还有重写机制。

 

缺点也很明显：

在相同的数据集的情况下AOF方式的文件要比RDB的大。

在做日志重放的时候很慢。

 

在Redis4.0中提供了两种混合的机制：

将AOF日志和RDB文件内容存放在一起，AOF日志是从持久化开始到结束这段时间的日志。在重放的时候，先加载RDB的文件，再重放增量AOF日志

重启的效率大大提升了。

 

转载于:https://www.cnblogs.com/lgxblog/p/11282186.html