redis持久化策略

redis持久化策略

Redis是基于内存操作的非关系型数据，基于内存操作的数据库优点就是处理快，但是一旦宕机，内存中的数据可能就会丢失。为了保证数据的持久性，redis提供了RDB和AOF两种持久化策略将内存中的数据持久化到磁盘上。

RDB持久化策略

RDB全称为Redis Database即redis数据库。采用二进制快照的方式将内存中的数据持久化到磁盘中，这样做的好处是什么呢？基于二进制的好处就是恢复快，压缩性好（内存占用少）。而快照呢？类似于我们在某时某刻按下手机快门键，把当前美好的景色拍下来。但是会有什么问题呢？问题就是数据在恢复的时候不完整。如何保证数据的完整性呢？该方法会在下面的内容中介绍。

如果往深了想，那什么时候完成内存到磁盘的持久化操作呢？可以通过查看redis.conf配置文件查看到有以下几种策略，也就是说900s内有1个写请求的时候，会刷入磁盘，300秒内有10个写请求，会刷入磁盘，60秒内有10000个请求会刷入磁盘。

save 900 1
save 300 10
save 60 10000

除了上述reids配置文件中的刷盘策略外，还有以下几种方式会进行刷盘操作，即输入sava和bgsave命令的时候，会进行刷盘操作，同时还有我们正常关闭redis的时候，也会进行刷盘操作。
那刷盘操作是如何实现的呢？是我们主进程完成还是子进程完成呢？答案不言而喻，主进程还有更重的事，肯定事fork一个子进程完成刷盘操作。具体来讲的话就是当触发RDB持久化的时候，主进程会fork一个子进程将当前在内存中的数据采用二进制压缩到一个新的rdb文件中，最后完成新旧rdb文件内容的替换。【注意】为何子进程能够读到内存中的数据，那就是父子进程共享同一片内存。
如果此时我们在执行bgsave的时候，发生数据的修改？怎么处理？RDB提供了写时复制的技术，也就是copy on write，具体来讲的话就是在有修改操作的时候，在内存中会出现一个修改的副本，bgsave会将当前的副本数据写入到rdb文件中。
以上就是对RDB持久化策略的理解！

AOF持久化策略

AOF也是Redis持久化策略的一种，采用追加命令的方式写入到磁盘中（追加的文件是appendonly.aof）。这个策略就能够极大的解决RDB持久化策略中所提到的数据不完整性问题。采用追加命令的方式的好处就是数据能够保证较强的完整性，但是不好出就是在恢复的时候还需要执行命令，恢复速度慢。
那同样一个问题AOF是什么时候完成刷盘呢？因为是追加命令，在redis.conf配置文件中给出了这几种刷盘方案。即操作一次刷盘一次，每秒进行刷盘，由操作系统完成刷盘操作。默认为每秒进行刷盘操作。

# appendfsync always
appendfsync everysec
# appendfsync no

AOF日志是如何实现的呢？具体来讲就是当我们执行一个写命令的时候，将数据先写入到内存中，然后追加命令。这里是先写命令，然后追加命令到日志中，为何这样设计？首先第一点如果要是先追加日志，我们不能够保证命令写的正确，第二点就是先追加日志，如果redis挂了，那数据就丢失了。因此先写命令，再追加日志是一个很好的解决办法。

因为AOF是采用追加命令的方式写入到文件中的，但是随着执行的命令增多，AOF终究会有爆的一天，这时候AOF重写就出现了，相当于将重复的命令，按照最后一次执行的追加到日志中。AOF重写分为以下两个过程：1次拷贝，2次日志。具体来讲的话，就是fork一个子进程将当前的数据拷贝到重写日志中，再有新命令来的时候，主线程会在aof缓冲区和aof重写缓冲区均追加新的命令，aof缓冲区保证数据不会丢失，aof重写缓冲区在恢复的时候保证数据的完整性。

【参考资料】
https://xiaolincoding.com/redis/base/redis_interview.html#aof-%E6%97%A5%E5%BF%97%E6%98%AF%E5%A6%82%E4%BD%95%E5%AE%9E%E7%8E%B0%E7%9A%84