redis同步数据本地存储采用的是通过fork系统调用来创建父子进程，子进程来把数据从内存落到磁盘中子进程不是把所有数据从父进程在拷贝一份，使用的是指针引用，copy on write？什么意思？这句话叫做写时复制。事写的时候他就复制，换言之，创建子进程中并不发生复制，只有在父进程一方想修改数据的时候才会定向地去复制数据，这样会有一个优势，就是创建进程变快了。同时根据经
验，不可能子进程或者是父进程，把所有数据都改一遍，也就是其实触发起复制的机会也
不是很大，明白什么意思吧？就是整个Linux，为什么我fork这个东西，它其实要解决我车进
门的速度，包括车也要出来，而且有数据导出这个事儿也不怕，就是把你这个数据要导出
的变量那个值也给你，从子进程带过去。copy-on-write是机制，内核机制，然后fork是系统调用。备份数据的时候是有时点性的，8点开始备份数据，那么只会保留8点之前的数据，如果备份完毕，服务器死了，那么8点之后的数据会丢失。
开启RDB的方式有2种:save和bgsave，通过rdb备份有时点性；
save会阻塞进程服务，只有在断电关机和清理才会用,bgsave会通过fork创建子进程；
在redis的配置文件有关rdb的配置：
dir /var/lib/redis/6379 rdb文件所在目录；dbfilename dump.rdb rdb文件名称；
rdb不支持拉链法，就一个rdb文件；save “” 表示不开启rdb，
save 900 1
save 300 10
save 60 10000
比如说save你可以写条多条，然后时间肯定是越来越久，然后操作数是越来越少，这
么一个规律，什么规律？比如说达到60秒了，然后你超过达到的操作数，一个是时间，一
个是操作数，60秒了，或者是操作数达到个10000了，那么这两个满足其中一个，就会写
RDB。如果说当60秒的时候还没有到1万刚到9，那么就进入61秒就进入300秒这个判断了。
那么你到9的时候还没到10，但如果到10了，他就开始触发了；或者到60秒的时候到9000，
那么也不触发。然后到300秒的时候，然后如果达到了9000已经大于10了，也会触发这个事
情。然后如果说你一直写很少，到900秒了，刚好一笔操作的时候，因为已经有900秒了，
到达900秒这时间点了发现你有一笔或两笔操作了，这时候得存一下，因为一笔、两笔操作
也挺值钱的，别丢了，因为时间不要太久了，一直没存过
aof很好理解，他的名字是Append only File就是只会向文件追加，追加的东西就是服
务器发生的写操作，redis的写操作记录到文件中，那么这个写操作记录到文件中，首先他
的第一个好处就是，因为伴随着每一个写，都会有一个写的到达，这个增删改的到达都会
写成文件，所以第一个好处就是，丢失数据会相对少，没错，像editlog就写日志，也像我们
mySQL的binlog一样。
是redis中 rdb和aof可以同时开启，但是注意了，但是如果开启了aof只
会用aof恢复，这点很重要，他只会用它来做恢复。即便你rdb、aof都开了，rdb也会落，aof
也会落。那么真正你重启服务器的时候，它只会拿aof恢复，因为aof恢复的相对的数据完整
性好一些，他就不做rdb恢复了。
AOF中包含RDB全量，增 加记录新的写操作。那么这样在恢复的时候就有一个
好处，因为AOF里面已经包了一个RDB了，所以你在做AOF的时候，rdb先一个做回复，先
把二进制的恢复到内存，再把AOF文件往后新增的这些东西再一条一条执行，那么新增的
数据相对少一些，速度相对快一些。没错，AOF是里面记录的日志，他等于要重新执行里
面的命令，所以他的弊端就是慢。相对于我们的 rdb慢，但是它的优势就是丢失数据少。
同时开启RDB和AOF，8点开启备份，8点之前的RDB备份，二进制快，8点之后到备份完成用AOF，这样能最快恢复的最全。
即使运行了十年的redis做AOF恢复，只要十年间没有溢出，那么恢复就不会内存溢出，redis是内存存储的，我的aof文件可以很大，但是里边能写成功的这个指令，都是在我redis没有内存溢出之前写进去的，也就是说你无论怎么恢复，最终恢复完的都是内存，这个有限空间里边的东西，不可能说我这个redis内存溢出了，本来10个g，12个g的操作都写进去了，在里边有效地，不可能的，因为都会有一些抵消的在里边出现，前面创建，后面肯定有一个删除，删除掉之后，后边还能拿被删除空间再去创建一个新的数据，所以只要他线性执行这个文件，最终就可以恢复里面所有的一个数据，而没有溢出这个事!
AOF的一个天生的弊端，什么弊端？根据这个问题是不引出了一个弊端。第一个体量大，体量无限变大，无限变大是一个好事儿。但是无限变大之后会带来一个问题，就是恢复慢，他的优点是丢数据少，缺点也是很明显的。所以这时候一般在很多软件当中都会对日志下手。
redis用另外一种方式，4.0以前的和4.0以后的，那么4.0以前怎么去做？其实4.0以前就
是，它会有一个机制叫重写。其实根据刚才描述，10年就是创建k，删除k、创建k，删除
k，那么这时候这个文件里边记了10个t，最后如果是创建k，删除k没有发生，其实创建k前
面的都是没有意义的，是可以互相抵消掉的。
还有一个就是我这10年可能给一个list，先是push 1,push 1…比如push了10万个1，但
是这10万个1是push了10万次，那么每条记录里边除了1这个元素之外，还有push。那么说白
了，其实完成这10万条记录，可以用一条记录，push，然后10万个1，参数push只会出1次，
这个单词只会出现一次，是不是有这么一种场景，比较浪费空间，对不对？所以所谓重写
就是抵消和整合命令，删除抵销的的命令，然后合并重复的，是归属于到一个key里面。
如果你对一个k创建+1，+1，+1，+1，incr把它加1，那么最后其实可以直接给他一个
incrby多少，这个加上去。这个文件在4.0以前，他的结果最终也是一个纯指令的日志文件。
那么相对于恢复的时候，成本还很高的，然后它偷偷地学习了，4.0以后，如果触发，这个
文件也开始记，但是它也是在重写的时候。
一旦重写了，比如那文件记到了几百兆了，他要重写了，他把几百兆的数据先用 rdb的
方式写到AR文件里边，也就是在重写的时候，将老的数据RDB到aof文件中，rdp其实做的就
是二进制，所以等于aof文件里边会存一些二进制的、不方便阅读的那些字节，先存到aof文
件里边，存完之后，然后将增量的以指令的方式 Append到AOF，也就是说间接的可以得出结论，AOF当中是包含rdb和增量日志的。
那么这时候就回到前面，是不是让aof当中是只记录增量不记录全量，那么这样得出一
个结论？他是一个混合体，AOF是一个混合题，然后利用了rdb的恢复快，利用了日志的全
量，数量保存得比较全，两个优点。是不是两个优点它用起来了？你8点触发的，那就把
8点内存里面数据写成rdb，写到aof文件里边，那么8点往后所有新的增删改就开始追记录
了，能听懂了吧？
appendonly no
no-yes 打开/关闭AOF，appendfilename “appendonly.aof” aof的名称；
appendfsync always appendfsync everysec appendfsync no
No是redis来了一个增删改的操作，比如说有4笔写，那么
他每笔会向那个buffer去写，然后no的时候就是redis不调flush，你内核什么时候满了，什么
时候刷，就完全听天由命，听从内核。那么这样会一个问题，可能会丢失一个buffer大小的
数据。然后always是什么意思，就是redis只要写了一个文件描述符，就把这个文件描述符写
进去，然后并同时调一个flush，buffer没有满，你也给我往磁盘写，所以always一定是数据
最可靠的，因为他每笔都立刻调了一个flush，顶多就是在调下来这瞬间，他没调成，断电
了，那么它顶多就是丢一条。
缓冲区大小是可以调的，不会很大，4k左右，然后那么redis还有一个东西就是每秒级别，这是他默认的，什么都叫每秒级别，redis
每一秒钟调一次flush，每秒钟调flush，那么每一秒钟调flush，它的丢失数据量是多少呢？有
这么一种概率，第一、buffer肯定没满，比如差那么一点点他就满了，因为它一满，内核就
把它刷刷了。所以从一秒开始，刚清完，到一秒的时候该刷flush了，在这一秒没到的前一
秒钟，它里边占了99%的空间，差一点就开始触发。但是没触发，所以他最大丢失是，差一
点点到内核buffer满，会丢这么多东西，也就接近丢一个buffer，但是这种概率太小，这毕竟
是个概率。因为你redis可能写的比较快，可能1秒钟之内你有3次或4次的buffer满了，就全刷
下去了。这时候可能buffer最后一次，就一秒刚你写了三条，结果该到一秒钟刷了，前面都已经触发过了，这三条还没有flush，那么丢了3条。所以每秒这种操作是折合在速度最慢的
always和速度最快的no之间的一种的，相对丢的数据量比较少。
