将某一时刻的内存快照，以二进制的方式写入磁盘。
手动触发：
save命令，使得Redis处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令，所以在生产环境慎用。
bgSave命令，会fork出一个子进程进行持久化，主进程只有在fork过程中会有短暂的阻塞，子进程创建dump.rdb之后，主进程就可以响应客户端请求了。
自动触发：
save m n：在m秒内，如果有n个键发生改变，则自动触发持久化，通过bgsave执行，如果设置了多个，只要满足其中一个就会触发，配置文件有默认配置
flushall：用于清空redis所有的数据库，flushdb清空当前redis所在库数据（默认是0号数据库），会清空RDB文件，同时也会生成dump.rdb，内容为空。
主从同步：全量同步时会自动触发bgsave命令，生成rdb发送给从节点。
优点：
（1）整个Redis数据库将只包含一个文件，dump.rgb文件，方便持久化。
（2）容灾性好，方便备份。
（3）性能最大化，fork子进程用来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独的子进程来进行持久化，主进程不会进行任何IO操作，保证了redis 的高性能。
（4）相对于数据集较大时，比AOF的启动效率更高。
缺点：
（1）数据安全性低，RDB是间隔一段时间进行持久化，如果持久化之间发生故障，会发生数据丢失，所以这种方式适合数据要求不严谨的时候。
（2）由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，当数据量较大时，可能会导致整个服务器停止服务几百毫秒，甚至一秒钟，会占用cpu。
以日志的形式记录服务器锁处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录，调用操作系统命令进行刷盘。
（1）所有的写命令会追加到AOF缓冲之中。
（2）AOF缓冲区根据对应的策略向硬盘同步操作。
（3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
（4）当Redis重启时，可以加载AOF文件进行数据恢复。
同步策略：
（1）每秒同步，异步完成，效率非常高，一旦出现系统宕机情况，那么这一秒钟修改的数据将会丢失。
（2）每修改同步：同步持久化，每次发生的数据变化都会被立即记录到磁盘中，最多丢一条不同步。
优点：
（1）数据安全
（2）通过append模式写文件，即使中途宕机也不会破坏已经存在的内容，可以通过redis-check-aof工具解决数据的一致性问题。
（3）AOF的rewrite模式，定期对AOF文件进行重写，以达到压缩的目的。
缺点：
（1）AOF文件比RDB文件大，且恢复速度慢。
（2）数据集大的时候，比rdb启动效率低。
（3）运行效率没有rdb高。
（1）AOF文件比RDB文件更新频率高，优先使用AOF还原数据。AOF比RDB更安全也更大。
（2）RDB性能比AOF好。
（3）如果两个都配了会优先使用AOF。