Redis_RDB持久化之写时复制技术的应用
背景：
最近生产环境中某个Set的Redis集群经常出现短暂的内存降低现象，经过查看日志是因为在RDB持久化所造成的内存突降（日志中：RDB: 4929 MB of memory used by copy-on-write ），其根本原理是RDB持久化的过程中，Redis借助操作系统提供的写时复制技术（Copy-On-Write，COW)，在执行bgsave（snapshot）快照的同时，会间接消耗额外的内存。
1.RDB持久化原理
RDB是一次的全量备份，即周期性的把Redis当前内存中的全量数据写入到一个快照文件中。Redis是单线程程序，这个线程要同时负责多个客户端的读写请求，还要负责周期性的把当前内存中的数据写到快照文件中RDB中，数据写到RDB文件是IO操作，IO操作会严重影响Redis的性能，甚至在持久化的过程中，读写请求会阻塞，为了解决这些问题，Redis需要同时进行读写请求和持久化操作，这样又会导致另外的问题：持久化的过程中，内存中的数据还在改变，假如Redis正在进行持久化一个大的数据结构，在这个过程中客户端发送一个删除请求，把这个大的数据结构删掉了，这时候持久化的动作还没有完成，那么Redis该怎么办呢？
于是Redis使用操作系统的多进程写时复制(Copy On Write)机制来实现快照的持久化，在持久化过程中调用glibc(Linux下的C函数库)的函数fork()产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求。子进程刚刚产生时，和父进程共享内存里面的代码段和数据段，也就是说，父子进程的虚拟空间不同，但其对应的物理空间（内存区）是同一个。这是Linux操作系统的机制，为了节约内存资源，所以尽可能让父子进程共享内存，这样在进程分离的一瞬间，内存的增长几乎没有明显变化。
(如果fork操作本身耗时过长，将导致主进程阻塞，可以执行info stats命令获取到latest_fork_usec指标，表示最近一次fork操作的耗时，若操作1s则需优化)
写时复制技术：
如果主线程收到的客户端的读写请求，需要修改某块数据，那么这块数据就会被复制一份到内存，生成该数据的副本，主进程在该副本上进行修改操作。所以即使对某个数据进行了修改，Redis持久化到RDB中的数据也是未修改的数据，这也是把RDB文件称为"快照"文件的原因，子进程所看到的数据在它被创建的一瞬间就固定下来了，父进程修改的某个数据只是该数据的复制品。这里再深入一点，Redis内存中的全量数据由一个个的"数据段页面"组成，每个数据段页面的大小为4K，客户端要修改的数据在哪个页面中，就会复制一份这个页面到内存中，这个复制的过程称为"页面分离"，在持久化过程中，随着分离出的页面越来越多，内存就会持续增长，但是不会超过原内存的2倍，因为在一次持久化的过程中，几乎不会出现所有的页面都会分离的情况，读写请求针对的只是原数据中的小部分，大部分Redis数据还是"冷数据"。
正因为修改的部分数据会被额外的复制一份，所以会占用额外的内存，当在进行RDB持久化操作的过程中，与此同时如果持续往redis中写入的数据量越多，就会导致占用的额外内存消耗越大。
那么在此期间写入的数据最终去哪了呢？
写入的数据还是存在了内存当中，并没有写入当前的持久化文件中，等到下次进行RDB持久化时才会把 ” 写入的数据 ” 落盘到RDB文件中。
bgsave：fork出的子进程开始根据父进程内存数据生成临时的快照文件，然后替换原文件。
这里解释一下几个跟 RDB 相关的参数：
- rdb_changes_since_last_save：自上次 RDB 后，Redis 数据的改动条数
- rdb_bgsave_in_progress：bgsave 是否在进行中，0 否，1 是
- rdb_last_save_time：上次 bgsave 的时间戳
- rdb_last_bgsave_status：上次 bgsave 的状态
- rdb_last_bgsave_time_sec：上次 bgsave 的持续时间
- rdb_current_bgsave_time_sec：正在执行的 bgsave 耗时，如果没有正在执行的，则为 -1
- rdb_last_cow_size：上次 RDB 过程中父进程与子进程相比执行了多少修改
根据 rdb_bgsave_in_progress 这一项为 0，可以判断在执行 info Persistence 命令时，bgsave 已经执行完成了。除了通过命令的方式触发 RDB 持久化之外，Redis 内部还有自动触发 RDB 的机制。比如以下场景：
- 配置文件中增加了类似 "save m n" 的配置，表示 m 秒内有 n 次修改则自动触发 bgsave。
- 新建立 Redis 主从复制时，主节点会执行一次 bgsave 保存 RDB 文件到本地，然后发送给从节点。
- 执行 shutdown 时，如果没有开启 AOF 则自动执行 bgsave。
- 哨兵模式发生主从切换时，会主动进行一次初始化操作，执行bgsave保存RDB文件到本地。
2 频繁执行全量快照的影响
如果频繁执行全量快照，会带来两方面的开销：
- 频繁将全量数据写入磁盘，会给磁盘带来很大压力，可能出现前面的没做完，后面的又开始了。导致恶性循环。
- bgsave 子进程需要通过 fork 操作从主线程创建出来，虽然，子进程在创建后不在会阻塞主线程，但是，fork这个创建过程本身会阻塞主线程，而且主线程内存越大，阻塞时间越长。
3 运维技巧
3.1 RDB 所在分区磁盘满了怎么办？
当遇到 RDB 所在分区磁盘满了，可以临时修改 RDB 路径，操作如下：
3.2 开启 RDB 压缩
Redis 支持对 RDB 进行压缩，参数为 rdbcompression，设置为 yes 表示开启（默认开启的）。压缩不但可以节省磁盘空间，在创建主从时，也能更快的将全量备份传给从实例，因此建议开启压缩功能。
3.3 RDB 文件损坏检测
当发现 Reids RDB 文件损坏时，可以使用 redis-check-rdb 进行检测，用法如下：
RDB looks OK! 说明rdb文件没有错误。
3.4 单机多实例的 RDB 备份
有些情况，我们会在单台服务器上部署多个 Redis 实例，但是使用配置文件中增加 save 的方式又怕几个实例 RDB 时间冲突，从而影响落盘速度。这种情况，可以使用脚本结合定时任务触发 bgsave 进行 RDB 备份。这样，同机器不同实例的 RDB 备份时间可以自定义错开，防止 IO 跑满带来的问题。（注意一定要设置好持久化的目录，防止多个实例共用同一目录）
4 备份建议
那么 Redis 究竟怎么备份更好呢？RDB 尽管恢复会快很多，但是可靠性比 AOF 低，但是如果只使用 AOF，又会存在恢复慢的问题，因此，Redis 4.0 提出了混合使用 AOF 日志和内存快照的方法。因此对于 Redis 的备份，建议如下：
- 数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；aof-use-rdb-preamble 配置设置为 yes ；（Redis5.0版本以后默认是开启的）
- 如果允许分钟级别的数据丢失，可以只使用 RDB；
- 如果只用 AOF ，优先使用 everysec 的配置选项，因为其介于可靠性和性能之间；
当然，如果有从实例，也优先考虑在从实例上进行备份。
