Redis优秀的性能是由于其将所有的数据都存储在内存中，同样memcached也是这样做的，但是为什么Redis能够脱颖而出呢，很大程度上是因为Redis有出色的持久化机制，能够保证服务器重启后，数据不会丢失。下面来看看Redis是如何持久化的。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。这两种方式可以单独使用其中一种，或者混合使用。
RDB方式介绍
RDB方式是通过快照完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照，并且存储到硬盘上。就像拍照一样，将这一瞬间的所有东西都保存下来。进行快照的条件在配置文件中指定。主要有两个参数构成：时间和改动的键值的个数，即当在指定时间内被更改的键的个数大于执行数值时，就会进行快照。RDB是Redis的默认持久化方式。
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间大约20-30分钟(++这里看网上说的，自己没有亲测过++)。
RDB方式配置
其实默认情况下这些都是设置好了的，可以不用修改，但是做优化的时候就需要进行修改。
修改配置文件/apps/redis/6379.conf，找到快照部分：SNAPSHOTTING
1、配置快照的触发条件
save 900 1
save 300 10
save 60 10000
# 如果指定的秒数和数据库写操作次数都满足了就将数据库保存
#
# 下面是保存操作的实例：
# 900秒（15分钟）内至少1个key值改变，则进行快照
# 300秒（5分钟）内至少10个key值改变，则进行快照
# 60秒（1分钟）内至少10000个key值改变，则进行快照
#
# 注释：注释掉“save”这一行配置项就可以让保存数据库功能失效
#
# 你也可以通过增加一个只有一个空字符串的配置项（如下面的实例）来去掉前面的“save”配置
#
# save ""
2、设置缓存方案
#在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。
#
#如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。
#
#然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。
stop-writes-on-bgsave-error yes
3、设置压缩
#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？
#默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。
#如果你想在存储的子进程中节省一些CPU就设置成'no'，
#但是这样如果你的kye/value是可压缩的，你的导出数据就会很大
rdbcompression yes
4、校验设置
#从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。
#这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，
#所以，为了达到性能的最大化，你可以关掉这个配置项。
#
#没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查。
rdbchecksum yes
5、设置rdb文件路径
# 导出数据库的文件名称
dbfilename dump.rdb
# 工作目录
# 导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。
# 只增的文件也会在这个目录创建（这句话没看明白）
# 注意你一定要在这个配置一个工作目录，而不是文件名称。
# 这个目录最好不要指定为相对路径，最好使用绝对路径
dir ./
RDB的工作机制和优缺点
当条件满足，redis需要执行RDB的时候，服务器会执行以下操作：
- redis调用系统函数fork() ，创建一个子进程。
2.子进程将数据集写入到一个临时 RDB 文件中。
3.当子进程完成对临时RDB文件的写入时，redis 用新的临时RDB 文件替换原来的RDB 文件，并删除旧 RDB 文件。
在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork那一刻的内存数据。
Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。
除了自动快照，还可以手动发送SAVE或BGSAVE命令让Redis执行快照，两个命令的区别在于，前者是由主进程进行快照操作，会阻塞住其他请求，后者会通过fork子进程进行快照操作。
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20～30秒钟。
通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。
RDB的优点是：
- 1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
- 2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
- 3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB缺点：
- 1.如果你需要尽量避免在服务器故障时丢失数据，那么RDB 不适合你。 虽然Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
- 2.每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。