当Redis在执行后台RDB,采用fork子进程的方式来处理。但主进程fork子进程后,此时的主进程依旧是可以接收写请求的,而进来的写请求,会采用Copy On Write(写时复制)的方式操作内存数据。也就是说,主进程一旦有数据需要修改,Redis并不会直接修改现有内存中的数据,而是先将这块内存数据拷贝出来,再修改这块新内存的数据,这就是所谓的「写时复制」。
写时复制你也可以理解成,谁需要发生写操作,谁就需要先拷贝,再修改。这样做的好处是,父进程有任何写操作,并不会影响子进程的数据持久化(子进程只持久化fork这一瞬间整个实例中的所有数据即可,不关心新的数据变更,因为子进程只需要一份内存快照,然后持久化到磁盘上)。
但是请注意,主进程在拷贝内存数据时,这个阶段就涉及到新内存的申请,如果此时操作系统开启了内存大页,那么在此期间,客户端即便只修改10B的数据,Redis在申请内存时也会以2MB 为单位向操作系统申请,申请内存的耗时变长,进而导致每个写请求的延迟增加,影响到Redis性能。
同样地,如果这个写请求操作的是一个bigkey,那主进程在拷贝这个bigkey内存块时,一次申请的内存会更大,时间也会更久。可见,bigkey在这里又一次影响到了性能。以上内容摘自《阿里开发者手册-Redis专题》电子书,点击https://developer.aliyun.com/ebook/download/7770 可下载完整版
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。