写时拷贝（Copy-on-Write）的出现就是为了解决这一问题，就像我们在这一节开头介绍的，写时拷贝的主要作用就是将拷贝推迟到写操作真正发生时，这也就避免了大量无意义的拷贝操作。在一些早期的 *nix 系统上，系统调用 fork 确实会立刻对父进程的内存空间进行复制，但是在今天的多数系统中，fork 并不会立刻触发这一过程：
在 fork 函数调用时，父进程和子进程会被 Kernel 分配到不同的虚拟内存空间中，所以在两个进程看来它们访问的是不同的内存：
- 在真正访问虚拟内存空间时，Kernel 会将虚拟内存映射到物理内存上，所以父子进程共享了物理上的内存空间；
- 当父进程或者子进程对共享的内存进行修改时，共享的内存才会以页为单位进行拷贝，父进程会保留原有的物理空间，而子进程会使用拷贝后的新物理空间；
在 Redis 服务中，子进程只会读取共享内存中的数据，它并不会执行任何写操作，只有父进程会在写入时才会触发这一机制，而对于大多数的 Redis 服务或者数据库，写请求往往都是远小于读请求的，所以使用 fork 加上写时拷贝这一机制能够带来非常好的性能，也让 BGSAVE 这一操作的实现变得非常简单。
总结
Redis 实现后台快照的方式非常巧妙，通过操作系统提供的 fork 和写时拷贝的特性轻而易举的就实现了这个功能，从这里我们就能看出作者对于操作系统知识的掌握还是非常扎实的，大多人在面对类似的场景时，想到的方法可能就是手动实现类似『写时拷贝』的特性，然而这不仅增加了工作量，还增加了程序出现问题的可能性。
到这里，我们简单总结一下 Redis 为什么在使用 RDB 进行快照时会通过子进程的方式进行实现：
- 通过
fork创建的子进程能够获得和父进程完全相同的内存空间，父进程对内存的修改对于子进程是不可见的，两者不会相互影响； - 通过
fork创建子进程时不会立刻触发大量内存的拷贝，内存在被修改时会以页为单位进行拷贝，这也就避免了大量拷贝内存而带来的性能问题；
上述两个原因中，一个为子进程访问父进程提供了支撑，另一个为减少额外开销做了支持，这两者缺一不可，共同成为了 Redis 使用子进程实现快照持久化的原因。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：
- Nginx 的主进程会在运行时
fork一组子进程，这些子进程可以分别处理请求，还有哪些服务会使用这一特性？ - 写时拷贝其实是一个比较常见的机制，在 Redis 之外还有哪里会用到它？
如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因，可以在博客下面留言，作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。
Reference
- Redis Persistence
- Understanding Redis Background Memory Usage
- FAQ · Redis
- Copy-on-write
- rdbSaveBackground · Redis
- Fork (system call)
- Which file in kernel specifies fork(), vfork()… to use sys_clone() system call
- Trying to understand fork() and Copy-on-Write (COW)
相关文章
- 011 为什么 MongoDB 使用 B 树
- 010 为什么 Redis 快照使用子进程
- 009 为什么 MySQL 使用 B+ 树
- 008 为什么总是需要无意义的 ID
- 007 为什么基础服务不应该高可用
- 006 为什么 MD5 不能用于存储密码
- 005 为什么你应该使用 Git 进行版本控制
- 004 为什么 TCP 建立连接需要三次握手
- 003 为什么 DNS 使用 UDP 协议
- 002 为什么使用通信来共享内存
- 001 为什么 Redis 选择单线程模型
本文转载自 Draveness 技术博客。
原文链接： https://draveness.me/whys-the-design-redis-bgsave-fork
评论