上一节简单分析了Redis数据持久化方式，点击这里查看。但是要考虑的一个问题就是，在Redis持久化的时候，有新的写入指令时，Redis是如何操作的。
1.RDB方式
1.1.同步方式
即save操作，在Redis执行save操作时，主进程阻塞，无法处理客户端指令，所以这种情况不用考虑在RDB持久化过程中的客户端写入指令如何处理。
1.2.异步方式
即bgsave操作，在Redis执行bgsave操作时，主进程会fork出一个子进程，子进程与主进程指向同一个内存空间。
当子进程在持久化过程中，如果主进行执行了写指令，那么主进程会将改数据，复制到一块新的内存中，生成一个数据副本，在副本上对数据进行修改。所以子进行进行持久化的内存中还是保存的原始数据。这也是RDB备份称为“快照”的原因：子进程在创建出来的一瞬间，要持久化的数据就已经固定了。具体执行流程示意图如下：
所以在RDB持久化过程中，写操作时，主进程会开辟新的内存空间，不影响原数据，主进程写如的新数据对子进程是不可见的，直至子进程持久化结束，主进程才会将新数据与原数据进行合并，而新的数据也会在下次持久化时写入RDB文件。
2.AOF方式
对于AOF方式，Redis服务会定期将执行的写入指令以追加的方式写入AOF文件。
⭐在说明AOF写文件之前，先要说明一个操作系统的文件写入与同步的机制：为了提高文件的写入效率，在现代的操作系统中，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正的将缓冲区中的数据写入到磁盘里。就像打开了一个文件，写入文件就像是调用了write函数，但是按下Ctrl+S保存时，才是真正将文件内容保存到磁盘，保存时才算是执行了同步操作，所以同步操作时才能真正保存AOF文件。
在Redis执行AOF持久化的时候，主进程接收到客户端写指令后，会将指令放入aof_buf 缓存区，当满足appendfsync配置的持久化条件后，进行持久化操作，将aof_buf缓存区的数据写入AOF文件。
在Redis服务器每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数。下面看一下《Redis设计与实现》中，关于AOF持久化appendfsync选项对应flushAppendOnlyFile 函数说明如下：
| appendfsync选项 | flushAppendOnlyFile函数行为 |
| always | 将 aof_buf 缓冲区中的所有内容写入并同步到 AOF 文件 |
| everysec（默认） | 将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间距离现在超过一秒钟，那么再次对 AOF 文件进行同步，并且这个操作是由一个线程专门负责执行的 |
| no | 将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，但并不对 AOF 文件进行同步，何时同步由操作系统来决定 |
下面对appendfsync的三个选项分别说明：
always：
服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最慢的一个，但从安全性来说，always 也是最安全的，因为即使出现故障停机，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
everysec：
服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上来讲，everysec 模式足够快，并且就算出现故障停机，数据库也只丢失一秒钟的命令数据。
no：
服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，至于何时对 AOF 文件进行同步，则由操作系统控制。因为处于 no 模式下的 flushAppendOnlyFile 调用无须执行同步操作，所以该模式下的 AOF 文件写入速度总是最快的，不过因为这种模式会在系统缓存中积累一段时间的写入数据，所以该模式的单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看，no 模式和 everysec 模式的效率类似，当出现故障停机时，使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。
