3. Fork原理
在默认fork的调用过程中，父进程需要将许多进程元数据（例如文件描述符、信号量、页表等）复制到子进程，而页表的复制是其中最耗时的部分（占据fork调用耗时的97%以上）。
Linux的fork()使用写时拷贝 (copy-on-write) 页的方式实现。写时拷贝是一种可以推迟甚至避免拷贝数据的技术。在创建子进程的过程中，操作系统会把父进程的「页表」复制一份给子进程，这个页表记录着虚拟地址和物理地址映射关系，此时，操作系统并不复制整个进程的物理内存，而是让父子进程共享同一个物理内存。同时，操作系统内核会把共享的所有的内存页的权限都设为read-only。
那什么时候会发生物理内存的复制呢？
当父进程或者子进程在向共享内存发起写操作时，内存管理单元MMU检测到内存页是read-only的，于是触发缺页中断异常（page-fault），处理器会从中断描述符表（IDT）中获取到对应的处理程序。在中断程序中，内核就会把触发异常的物理内存页复制一份，并重新设置其内存映射关系，将父子进程的内存读写权限设置为可读写，于是父子进程各自持有独立的一份，之后进程才会对内存进行写操作，这个过程也被称为写时复制（Copy On Write）。
4. Fork的痛点
在原生fork下，在父进程调用fork()创建子进程的过程中，虽然使用了写时复制页表的方式进行优化，但由于要复制父进程的页表，还是会造成父进程出现短时间阻塞，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长。
我们在测试中很容易观察到fork产生的阻塞现象，以及fork造成的Redis访问抖动现象。
4.1 测试环境
Redis版本：优化前Redis-server
机器操作系统：无Async-fork特性的系统
测试数据量：21.63G
127.0.0.1:6380> info memory # Memory used_memory:23220597688 used_memory_human:21.63G
4.2 阻塞现象复现
在使用Redis-benchmark压测的过程中，手动执行bgsave命令，观察fork耗时和压测指标TP100。
使用 info stats 返回上次fork耗时：latest_fork_usec:183632，可以看到fork耗时183毫秒。
在压测过程中分别不执行bgsave和执行bgsave，结果如下：
# 压测过程中未执行 bgsave [root@xxx bin]# Redis-benchmark -d 256 -t set -n 1000000 -a xxxxxx -p 6380 ====== SET ====== 1000000 requests completed in 8.15 seconds 50 parallel clients 256 bytes payload keep alive: 1 99.90% <= 1 milliseconds 100.00% <= 1 milliseconds 122669.27 requests per second # 压测过程中执行 bgsave [root@xxx bin]# Redis-benchmark -d 256 -t set -n 1000000 -a xxxxxx -p 6380 ====== SET ====== 1000000 requests completed in 13.97 seconds 50 parallel clients 256 bytes payload keep alive: 1 86.41% <= 1 milliseconds 86.42% <= 2 milliseconds 99.95% <= 3 milliseconds 99.99% <= 4 milliseconds 99.99% <= 10 milliseconds 99.99% <= 11 milliseconds 99.99% <= 12 milliseconds 100.00% <= 187 milliseconds 100.00% <= 187 milliseconds 71561.47 requests per second
从压测数据可以看到，单机环境下压测，压测时未执行bgsave，TP100约1毫秒；如果压测过程中，手动执行bgsave命令，触发fork操作，TP100达到187毫秒。
4.3 Strace跟踪fork过程耗时
strace 常用来跟踪进程执行时的系统调用和所接收的信号。
$ strace -p 32088 -T -tt -o strace00.out 14:01:33.623495 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fbe5242fa50) = 37513 <0.183533> 14:01:33.807142 open("/data1/6380/6380.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 60 <0.000018> 14:01:33.807644 lseek(60, 0, SEEK_END) = 8512 <0.000017> 14:01:33.807690 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=528, ...}) = 0 <0.000010> 14:01:33.807732 fstat(60, {st_mode=S_IFREG|0644, st_size=8512, ...}) = 0 <0.000007> 14:01:33.807756 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe52437000 <0.000009> 14:01:33.807787 write(60, "35994:M 21 Mar 14:01:33.807 * Ba"..., 69) = 69 <0.000015> 14:01:33.807819 close(60) = 0 <0.000008> 14:01:33.807845 munmap(0x7fbe52437000, 4096) = 0 <0.000013>
由于Linux中通过clone()系统调用实现fork()；我们可以看到追踪到clone系统调用，并且耗时183毫秒，与 info stats 统计的fork耗时一致。
5. Async-fork
鉴于以上linux原生fork系统调用的痛点，对于像Redis这样的高性能内存数据库，将会增加fork期间的用户访问延迟，论文中设计了一个新的fork（称为Async-fork）来解决上述问题。
Async-fork设计的核心思想是将fork调用过程中最耗时的页表拷贝工作从父进程移动到子进程，缩短父进程调用fork时陷入内核态的时间，父进程因而可以快速返回用户态处理用户查询，子进程则在此期间完成页表拷贝。与Linux中的默认原生fork相比，Async-fork显著减少了Redis快照期间到达请求的尾延迟。
5.1 Async-fork 的挑战
然而，Async-fork的实现过程中，实际工作并非描述的这么简单。页表的异步复制操作可能导致快照不一致。以下图为例，Redis在T0时刻保存内存快照，而某个用户请求在T2时刻向Redis插入了新的键值对（k2, v2)，这将导致父进程修改它的页表项（PTE2）。假如T2时刻这个被修改的页表项（PTE2）还没有被子进程复制完成， 这个修改后的内存页表项及对应内存页后续将被复制到子进程，这个新插入的键值对将被子进程最终写入硬盘，破坏了快照一致性。（快照文件应该记录的是保存拍摄内存快照那一刻的内存数据）
图片来源于：参考资料[1] 第8页
