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文件的内容
