redis持久化机制

redis中的数据默认是存到内存中的，存到内存中的数据 会不会丢失？不给他持久化到磁盘上，是有可

能丢失的 。有的时候需要使用redis的持久化机制。

reids的持久化机制有两种 RDB AOF

RDB持久化机制

RDB持久化机制是redis默认采用的持久化机制，这种机制是全量备份的机制。每次执行持久化操作，

redis都会把内存中所有数据读取一遍 ，然后存到磁盘上。

往磁盘同步数据 也可以手动执行redis的命令 ，save命令 ，另外一个是bgsave命令 。执行save命令或

者bgsave命令就会把内存中所有的数据 同步到磁盘的 dump.rdb文件中。

bgsave是 采用后台再开启一个子进程的方式来同步数据，他不会阻塞当前redis的主进程。现在一般都

会采用bgsave的方式来同步数据，save很少用了。

save会阻塞当前的主进程。就是在保存数据的这一段时间，比如你要花个5秒，主进程就不能进行对外提供服务了，这个肯定是灾难性的。

一般用bgsave，bgsave就是在开一个线程，类似于多线程，让它专门去干备份的事情。主进程继续提供服务

修改redis.conf配置文件

vim redis.conf

把这些去掉就是关闭，配置rdb的方式。

如果任意满足下面几种行为将会保存数据备份数据

900秒（15分钟）至少有一个key被修改

300秒 （5分钟）至少有一个key被修改

60秒 至少有一个key被修改

三个条件都不满足的情况下，数据将丢失。

dbfilename dump.rdb 就是配置保存文件的名称

dir ./ 是保存的文件保存到哪个路径下 ， . 就是当前目录下

关掉 redis，再打开redis，查看下name是否还有

正常结束服务的情况下，默认会触发一次持久化，所以刚才保存的数据保存上了。

如果测试没有保存的情况。杀进程，或者虚拟机停电，

原先有一个主进程，主进程负责提供服务，往里面写数据、读数据，加入原先触发bgsave之前，内存里肯定有数据，物理内存的数据就是原先的数据，主进程通过key记录数据，内存里每个数据都有地址，主进程中记录这些地址，读取数据。如果现在执行了bgsave的命令，这个命令不管是手动执行还是自动执行，都会由主进程再创建一个子进程，由操作系统中fork的命令创建一个子进程，这个子进程里面也会记录内存里面这些数据的地址。开始fork创建出来的子进程和主进程里面记录的地址一样。主进程操作这块儿数据，子进程操作那块儿数据，互补影响。

最大问题：物理内存4G, fork出来进程后，得把内存立刻增大一倍，可能原先的数据可能已经存了1G数据了，现在fork进程，立刻内存变成了2G了，这样肯定是不能接受的。这意味着物理机只有4G内存，被redis使用用的顶多2G,2G占满之后，你要fork出来一份，那么物理内存立刻就满了。

主进程和子进程都操作同一块物理内存去做东西。

为了解决数据同步的问题，采用了一种机制：copy on write ,即写时复制

在子进程操作这块内存数据的时候，操作系统会把这块内存锁定，变成readonly 只读模式，如果要改，复制一份

RDB的默认 丢失数据的可能性是比较大的，如果对数据的持久化有更高的要求，可以使用AOF的机制去

同步数据

AOF持久化机制

AOF 持久化机制是 采用增量备份的机制。 AOF的持久化机制是 有一个类似于日志文件，然后我们每次

执行redis命令， 这些命令都会追加到这个类似的日志文件中。AOF的持久化文件 一般都会RDB的持久

化文件要大。

redis 默认是没有开启AOF持久化机制的。

设置开启 AOF日志

appendonly no 默认不开启AOF日志

这里 将 no 改为yes ，开启AOF日志

配置AOF缓存中的数据同步到AOF文件的机制

everysec 是每秒同步一次，所以最多只会丢失1秒的数据。

此时appendonly.aof长度为0，因为还没有往里面写东西。

查看appendonly.aof文件的内容