2017-12-01
redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢？redis借助了fork命令的copy on write 机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。
注意：redis的RDB文件也是Redis主从同步内部实现中的一环。 不足：一旦数据库出现问题，那我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。 对于可以忍受的业务，推荐使用RDB方式进行持久化，因为开启RDB的代价并不高。但是对于对数据安全性要求极高的应用，Redis引入了：AOF日志。
copy on write 机制
copy-on-write机制，简称COW，是一种用于程序设计中的优化策略。
基本思路是：一开始大家共享同一内容，当某个人想要修改这个内容时，才会真正把内容Copy出去形成一个新的内容然后再改，是一种延时懒惰策略。
copy-on-write容器，即写时复制容器。通俗理解就是当我们忘一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行copy，复制出一个新的容器，然后新的容器里添加元素，添加之后，再将原容器的引用指向新的容器。
好处是：可以对copy-on-write容器进行并发读，而不需要加锁，因为当前容器不会添加任何元素。所以copy-on-write容器也是一种读写分离的思想，读和写不同的容器。
缺点：内存占用问题和数据一致性（不能保证实时一致性，即写入的数据能够马上读到）问题。
注意：1.减少扩容开销；2.使用批量增加。
AOF日志，全称append only file，是一个追加写入的日志文件，是可识别的纯文本，内容就是一个个的redis标准命令。
appendfsync的三个设置项
appendfsync no
appendfsync everysec
appednfsync always
RDB特性：
fork一个进程，遍历Hashtable，利用copy-on-write，把整个db dump保存下来。
save,shutdown,slave之前crash，则中间的操作无法恢复。
AOF特性：
把写操作指令，持续的写入一个类似日志文件。
粒度较小，crash后，只有crash前没有来得及做日志的操作无法恢复。
二者区别：
AOF是持续用日志记录写操作，crash后利用日志恢复；
RDB是平时写操作时不触发写，只有手动提交save命令或关闭命令时，才会触发备份操作。