Redis的数据持久化

目录

应用背景：

持久化方式的分类：

RDB方式：

RDB配置：

 RDB面试题：

AOF方式：

AOF配置：

AOF面试题：

如何选择合适的持久化方式：

---

应用背景：

        Redis是一个缓存的数据库，断电时有可能会发生数据丢失。如果没有持久化操作的话，因为断电等其他因素导致redis挂了，其中的数据就会丢失。

        所以需要持久化操作来保证数据的安全，就是把缓存里的数据整一份儿到磁盘里面。

持久化方式的分类：

RDB方式：

        RDB方式是redis默认的持久化方式。按照一定的时间将内存中的数据以快照的形式存储到本地磁盘里去，产生一个文件dump.rdb。

        通过手动（save-阻塞式，bgsave-异步方式）或者周期性方式保存redis。

RDB配置：

        是默认配置的，也可以自己配置

        配置文件在挂载目录下的redis.conf里

        

修改规则如下：

        

# 这里表示每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。

save 60 1000

# 持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
    
# 在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。
rdbcompression yes

# 一个CRC64的校验就被放在了文件末尾，
当存储或者加载rbd文件的时候会有一个10%左右的性能下降，
为了达到性能的最大化，你可以关掉这个配置项。
rdbchecksum yes

# 快照的文件名
dbfilename dump.rdb

# 存放快照的目录，一般存放在data文件夹下，可以修改为自己的文件夹
dir /var/lib/redis

 RDB面试题：

        1.Redis中的save和bgsave有什么区别？

        答：save执行一个同步的操作，将当前数据库中的数据以快照的形式保存到磁盘当中。

              bgsave表示一个异步的操作，执行以后会返回一个OK，然后fork出一个新的子进程，原来的redis进程会继续处理客户端命令，子进程负责将数据保存到磁盘。

        2.RDB有什么优点：

        答：1.只有一个文件dump.rdb,方便持久化。

               2.容灾性好，一个文件可以保存到安全的磁盘。

               3.性能好，用子进程来进行 读写操作，而主进程不会有任何io操作，性能比较高。

               4.数据较大时，比AOF启动效率高。

       3.RDB有什么缺点？

        答：安全性低，因为是每隔一段时间保存一次，如果在两次保存时间的中间redis发生故障，那么会丢失一部分数据。

AOF方式：

        AOF是通过写操作日志的方式，记录redis数据的一些变化，默认是关闭的。

        关闭redis后，重新启动，redis会读取日志中的信息恢复数据。

        

 

        当两种方式同时开启时，redis会优先选择AOF恢复。

AOF配置：

        配置方式文件与RDB一样。

        

# 是否开启AOF，默认关闭，默认是no，改成Yes会开启AOF
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式：
# appendfsync always #每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
    
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

AOF面试题：

        1.如何理解AOF中重写操作？

        答：因为redis中可以存储的数据是有限的，很多数据会自动过期，只有一部分常用的数据会存放在redis内存中，所以很多之前清理掉的数据还保存在日志中，会导致日志文件越来越大。

        所以后台会每隔一段时间就进行重写操作，会重写构建一套最新的日志，覆盖掉之前的老日志，保证文件不会特别大。

        2.AOF方式的优点：

        答：1.安全性好，可以更好的保证数据不丢失，AOF每隔一秒会通过一个后台的线程执行一次fsync操作，最多丢失一秒的数据。

               2.通过append方式写入文件，即使在写入的过程中redis死机了，也可以通过aof工具修复。

               3.没有任何磁盘寻址的开销，所以写入性能非常高。

               4.在后台重写操作时，也不会影响客户端的读写。因为在重写时，会对其中的日志进行压缩，创建一份恢复数据时需要的最小日志出来。再创建新文件的时候，老得文件还会照常写入。当合并的日志文件准备好时，直接替换新的日志文件。

               5.AOF机制的rewrite模式，日志文件没被合并重写之前，可以删除其中的某些命令（比如误操作的flushall）.

        3.AOF机制的缺点：

        答：1.AOF文件比RDB文件大，且恢复速度慢。

               2.数据集大的时候，比RDB启动效率低。

               3.AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

如何选择合适的持久化方式：

        答：1.不要仅仅使用RDB，那样会使你丢失很多数据。

                2.不要仅仅使用AOF，因为AOF的速度不快。定时使用RDB快照非常适合数据库备份。

                3.同时使用两种方式，用AOF保证数据不丢失，用RDB来做不同程度的冷备。

                4.如果你不想要你的数据，你可以不要做持久化方式。