在进行镜像备份时,是否进行压缩。
如果没有触发自动快照,需要对Redis执行手动快照操作,save和bgsave命令来手动快照,两个命令是：
SAVE：由主进程进行快照，会阻塞其他请求。 BGSAVE：通过fork子进程进行快照，不会阻塞其他请求。注意:由于Redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候,必须保证有16G的内存,要不然会启用虚拟内存,性能非常的差。
快照的过程如下：
Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）； 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件； 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。（注意：会存在写一部命令压缩缓存区，记录写入rdb文件时候的操作）在执行fork的时候操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork时那一刻的内存快照数据。
通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得可以通过定时备份RDB文件来实现Redis数据库备份。
快照的过程压缩分析：
RDB文件是经过压缩（上文介绍了：可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。
快照的读取加载过程：
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。 通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。 RDB 的优缺点优点：
适合大规模的数据恢复。 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。缺点：
数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件。 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。(回写和覆盖的时候用的是主进程)。RDB与AOF二者选择的标准（虽然还没有讲AOF，提前普及）
如果系统是愿意牺牲一些性能，换取更高的缓存一致性（aof） 或者是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。
总结 Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。 RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。 Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。所以Redis的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
到此这篇关于Redis RDB技术底层原理详解的文章就介绍到这了,更多相关Redis RDB底层原理内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
