其实redis就是一种高级的以键值对形式存储数据的数据库，而它的好处就是他可以支持数据的持久化，其实redis之所以会有这样的优点，主要是因为，redis的数据都是存放在内存中的，如果不配置持久化，那么在redis进行重启的时候，就会造成数据的丢失，于是redis开启了数据的持久化功能，将所有的数据保存到磁盘中，当redis重启之后，就可以直接从磁盘中恢复数据，所以redis的持久化功能，主要就是为了防止服务器宕机而造成的数据丢失。
redis也提供了两种不同的持久化方式：
第一种是：RDB持久化，RDB是Redis DataBase的缩写，redis默认的持久化方式，简单来讲就是将redis在内存中的数据库记录按照指定的时间转存到磁盘当中，其实就是一定时间间隔内对你的数据进行一个快照存储，在默认的情况下，redis在完成快照存储后就会将这些数据保存在一个dump.rdb的文件中，当redis运行的时候，RDB就会将内存中的数据集存储到磁盘当中，在redis进行重启的时候，就可以通过载入RDB文件到RDB程序进行数据的同步恢复。
优点：因为服务区在执行保存dump.rdb文件时，首先需要redis去调用forks()时，就会同时拥有父进程和子进程，而子进程其实就是将这些数据写入到一个临时的RDB文件当中，当子进程完成写入后，redis就会用一个新的RDB文件替换掉旧的RDB文件，并且将旧的RDB文件删除，所以因为这样的工作方式，RDB持久化方式就只有一个dump.rdb文件，非常方便持久化，而且由子进程完成写的操作，让主进程可以继续处理命令，这样可以使得IO最大化，使用单独的子进程来进行持久化，主进程就不会进行任何的IO操作，这样可以保证redis的高性能。
缺点：因为RDB是按照指定的时间每隔一段时间就要进行一次持久化，如果在持久化的过程中redis发生故障，那么依然会发生数据丢失，所以一般都在数据要求不太严谨的时候使用这种方式。
第二种：AOF持久化，AOF是Append Only File的缩写，默认AOF是不开启的，需要在redis.conf配置文件中手动开启，这种持久化方式就是将redis执行的每一次命令记录到单独的日志文件当中，当还原数据时，只需要将这些备份的指令再重新执行一遍即可。redis的配置文件中存在三种不同的AOF持久化方式，分别是：
appendfsync always：每次有数据修改发生时都会写入AOF文件，这样会严重降低Redis的速度
appendfsync everysec：每秒钟同步一次，将多个写命令同步到硬盘
appendfsync no：让操作系统决定何时进行同步
而且由于AOF持久化对日志文件的写入操作采用的是append模式，使用这种模式的好处就是，即使在写入的过程中出现宕机现象，也不会破坏日志文件中已经存在的内容，然而如果我们本次操作只写入了一半数据就出现了系统崩溃问题，也不用担心，在redis下一次启动之前，我们可以通过redis-check-aof工具来帮忙解决这种数据一致性的问题。
优点：数据安全，因为AOF有写回策略机制，比如：always，意思就是可以在每个执行命令执行完之后，立刻同步的将日志写回磁盘，而且AOF持久化快，能够减少数据丢失的量，在配置了everysec的情况下最多只会丢失秒级数据。
https://b23.tv/8mP4VCF
https://b23.tv/HtAoFSY
https://b23.tv/AQfC1t0
https://b23.tv/SxNsEZm
缺点：在同等数据量的情况下，AOF文件的大小要比RDB文件大很多，如果使用它进行内存的恢复需要一定的时间。
针对以上阐述，在选择持久化方式上，一般来说，如果想要达到足以媲美关系型数据库的数据安全性，那么就应该同时使用两种持久化功能（redis4.0开始支持RDB和AOF混合持久化），在这种情况下，当redis重启的时候就会优先载入AOF文件来恢复原始数据，因为通常这种情况下，AOF文件保存数据集要比RDB文件保存数据集更加完整，如果你非常关心你的数据，但是仍然可以承受一些保持在分钟之内的数据丢失，那么你可以只选择使用RDB持久化，因为它可以更快，但是会有一些分钟之内的数据丢失是它的缺点。
有很多人都只使用AOF持久化，但其实不太推荐，因为定时生成RDB快照非常方便于进行数据库的备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快，除此之外，使用RDB也可以有效规避AOF程序的bug，当然如果你只希望你的数据在服务器运行的时候存在，也可以不选择使用任何持久化方式。
