Redis实现持久化的策略

RDB（Redis DataBaes）策略

1.1.定期备份的持久化策略

RDB定期的把我们Redis中的内存的数据，都写入硬盘中，并生成一个快照
下面是redis的工作流程

1.2.定期的两种方式

1.手动触发

可通过redis客户端，执行命令的方式生成快照

通过命令触发：save

使用save触发的时候redis就会全力以赴的进行快照生成操作，此时就会阻塞redis的其他客户端命令
一般不建议使用该命令进行备份

可通过i命令触发：bgsave

使用bgsave进行触发不会影响redis服务其它客户端的请求命令，因为bgsave使用的时多进程的方式进行持久化。

bgsave的操作逻辑:

1.执行该命令时，会首先判定当前是否有在执行的子进程
比如现在已经有一个子进程正在执行bgsave,此时就吧当前的bgsave直接返回
2.如果没有其他的工作子进程，就通过fork这样的系统调用创建一个子进程出来
3、子进程负责进行写文件并生成快照的过程，父进程继续接受来自客户端的请求，继续提供正常的服务。
4.子进程完成整体的持久化之后，就会通知父进程，父进程收到消息后就会更新一些统计信息，子进程就可以销毁结束了。
5.在bgsave这个场景中，绝大部分数据时不需要拷贝的，这就保证了拷贝的整体时间是可控的，高效的，其实这和他的拷贝机制有关，可以参考一下下面的说明。

fork是怎么进行操作的呢？

1.fork是linux系统提供的一个创建子进程的api(系统调用)如果是其他系统比如windows创建子进程的就不是fork
2.fork创建子进程的过程简单粗暴，直接把当前的父进程复制一份，作为子进程就好了（会复制：pcd、虚拟地址空间（内存中的数据）、文件描述表符…）
3.一旦复制完成，父进程和子进程就是两个独立的进程了，就各自去执行自己的操作了
4.fork随着的进行，子进程的内存里就有了和父进程一模一样的变量
5.接下来吧子进程中的数据进行持久化，也就相当于吧父进程中的数据进行了持久化。

fork的操作开销会不会引起其他任务阻塞呢？

其实大可不必担心，因为此处的开销是很小的，对数据的拷贝不是无脑的复制，而是通过“写时拷贝机制”来实现的，需要了解写时拷贝的小伙伴可以自行去了解一下。

redis持久化生成的文件

1.redis生成的rdb文件是存放在redis的工作目录中的，也是在redis配置文件中进行设置的。
2.redis生成的镜像文件是以压缩文件（.rdb）的形式存在的，这样的操作需要消耗一定量的CPU空间，但是会节省存储空间，就比如HTTP协议中的响应数据就经常被压缩。
3.这个rdb文件我们尽快不要去动它，一旦损坏可就麻烦了（如通过网络传输导致文件损坏），因为redis服务器重新启动时，就会尝试去加载这个rdb文件，如果发现格式或其他错误就会加载失败，redis就会无法启动。
4.redis也提供了相应的检查rdb文件的的工具。
5.到这里很多同学就会说了，万一在重新生成镜像快照的时候，出现断电或其他状况，影响了这个新生成的这个rdb文件，那我这个redis是不是就无法启动了，这里redis官方就提供了这样的一种机制去避免这种情况的发生，就是每当重新生成会先把旧的rdb文件先存储到一个临时文件夹中，当这个快照重新生成完毕之后，再删除之前的rdb文件。

2.自动触发

在redis配置文件中，设置触发间隔时间或每次产生多少修改触发。

AOF（Append Only File）策略

##2.实时备份进行持久化