1.RDB持久化
save 可以手动触发，但是会占用主进程，阻塞用户请求，所以一般是在Redis正常停机时，自动触发一次save操作。
bgsave 可以手动触发，会额外创建一个字进程去处理备份操作，对主进程影响较小（因为主进程其实还是会阻塞一段时间用来复制主进程中的数据到子进程）。可以打redis.conf配置文件中，通过 save 5 1的格式进行自定义配置，会在一段时间内的几次修改之后进行异步的备份操作。
bgsave底层原理
用linux来进行解释，linux物理内存不允许直接操作，所以所有进程对于物理内存的修改都落在与之对应的虚拟内存之上，这个时候就需要有一个映射将物理内存与虚拟内存进行关联，所以就有了页表。那么bgsave过程中创建子进程的话也就是复制一个页表映射，子进程通过复制的页表就可以操作物理内存，所以不会影响主进程。
复制的原理
复制操作是进行了 copy-on-write 技术的操作：
1.主进程进行读操作的时候，数据是共享的。
2.主进程进行写操作的时候，需要把原来的数据复制一份，然后对这个备份进行操作，当然你再次去读取这个修改后的数据的话就会去副本中读取。
2.AOF持久化
原理
首先AOF持久化可以理解为命令文件备份。同样的话它是在主线程处理内存数据之后执行这个aof记录操作，然后的话是内存级别的，所以效率较高，不会影响其他进程的业务执行。
既然是在内存中记录的就也会涉及持久化问题，所以有几种策略，通过redis.conf配置文件中的 appendonly 配置项开启AOF持久化，然后通过appendfsync 配置项选择不同的策略：
- aways
在每次的命令执行之后，都会进行一次AOF文件的持久化，这个操作可以保证数据的安全性，基本不会出数据丢失问题，但同时每次操作都进行写入也是会有磁盘I/O，所以性能也是最低的。 - everysec
它是每一秒中，会把缓冲区中的数据一次性持久化到磁盘中，所以一秒钟之内是不会影响其他进程，性能是较高的，同样的话还是可能会出现数据丢失的问题，但是最多只会丢失这一秒之内的数据。 - no
它则是将命令放入AOF缓存区中之后就不再处理它，而是由操作系统来决定什么时间来进行持久化，当然性能无疑是三种中最高的，但同时也是最不安全的，可能会丢失大量数据。
