本文已参与「新人创作礼」活动，一起开启掘金创作之路。
持久化
Redis 为了保证效率, 数据缓存在了内存中, 但是会周期性的把更新的数据或修改的操作写入文件中, 以保证数据的持久化.
一般使用异步后台进程进行持久化，包括RDB、AOF、主从同步（持久化到其他机器）
rdb和aof工作原理与优缺点
RDB流程：默认的持久化方式，将数据以快照的形式保存到硬盘(dump.rdb)。
（1）bgsave命令通知主进程fork出子进程，若存在子进程则直接返回，若没有则主进程会fork子进程
（2）fork子进程时，父进程阻塞
（3）主进程fork完成后继续执行其他命令，子进程存储父进程内存中的数据。
（4）子进程完成保存后通知父进程替换旧文件。
主进程和子进程会同时操作，若子进程读取数据时父进程要修改数据，会将数据复制一份副本进行修改（操作系统中的写时复制技术），修改完后替换回去。
优点：（1）性能最大化，fork 子进程保存数据，主进程不进行IO操作（2）RDB文件紧凑，适合用于备份和灾难恢复。（3）RDB在恢复大数据集时比AOF效率高。
缺点：（1）阻塞，fork子进程时阻塞父进程（2）数据安全性低，持久化间隔时间内 ，数据可能丢失。
AOF：将Redis执行的写命令记录日志文件中，恢复时会重新执行日志文件中的操作；
备份：命令写入缓存区，再刷入AOF文件，刷入时机（每次刷盘、操作系统自动判断、配置每隔1s）
优点:（1）数据更安全，默认每隔一秒记录一次（可每次都记录，但影响性能）.（2）易解决一致性问题，对日志进行追加，若宕机了可通过 redis-check-aof 修复。（3）自动重写，AOF文件太大时，会在后台进行重写，新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
缺点：（1）AOF 文件更大，且恢复速度慢。（2）大数据集的数据库启动时启动效率低。
AOF重写流程：
（1）bgrewriteaof命令通知主进程fork子进程（正在aof重写则返回，正在bgsave则推迟）
（2）fork子进程时，父进程阻塞。
（3）主进程fork完成后继续执行，子进程有父进程fork时的快照数据了，将最小恢复命令集合写入AOF文件
（4）防止新操作的数据丢失，主进程fork结束后，会将新命令存入rewrite_buf中
（5）子进程写入完成后，通知父进程替换旧文件，父进程会将rewrite_buf中的数据写入新AOF文件。
rdb-aof混合持久化
Redis4.x，在AOF重写时先BGSAVE命令生成RDB文件放到AOF文件的头部，新命令追加到AOF文件。
如何选择合适的持久化方式
（1）对数据安全性要求高，应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
（2）数据允许部分丢失，可以只使用RDB持久化。
（3）有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，使用RDB还可以避免AOF程序的bug。
