3.3redis数据持久化方式

redis的数据持久化是把数据写入到硬盘当中。
这里来讲讲redis的数据持久化方式
1）RDB模式 Redis DataBase
2）AOF模式 Append-only file

------------------------------------------分割线-----------------------------------------------
RDB是一种快照的方式 默认开启
我理解的快照是快速拍照
在某个时间节点，把所有的数据写入一个临时文件 rdb后缀，用这个文件去做持久化。
首先 这个时间节点是可以配置的在redis.conf文件里有这样三个串串
save 900 1 //更改了1个key900s做一次持久化
save 300 10 //更改了10个key300s做一次持久化
save 60 10000 //更改了1万个key60s做一次持久化
可以根据实际需求对时间和key的数量做修改
我的redis里把save 改成了bgsave
那么这两个什么区别呢？加粗样式
save 会阻塞所有的客户端请求
bgsave 顾名思义嘛 background 会在后台运行并不会阻塞客户端请求 这一点在高并发环境中尤其重要
其次这个持久化动作由谁来完成呢
redis 会fork一个子进程来做这个事情
RDB模式的优缺点
优点：性能不会降低，该过程由另外一个子进程来完成，主进程不会受到干扰保证了高性能。
缺点：显而易见的，如果在两个持久化时间节点之间，redis发生故障。则会发生数据丢失。

-------------------------------------分割线------------------------------------------------------
AOF 更类似于是一个实时日志的概念 默认关闭
当我们执行事务操作时（对数据进行了变更），就会把数据变更写入到磁盘里面。
AOF模式的优缺点
优点：数据丢失最小
缺点：
1）这个过程会降低redis的性能。因为该过程当中会写两份文件，一，数据写入磁盘；二，写aof文件，后坠是aof。
2）因为其是一个实时文件，每一个数据的操作都会被记录。所以当我们的数据操作频繁时，会导致aof文件变的很大（惊喜哦 有解决方案的）
在redjis的配置文件里有这样一个配置，是的aof文件可以重写。
auto-aof-rewrite-percentage 100 //当目前的aof文件超过上一次aof文件大小的百分之100时 会进行重写
auto-aof-rewrite-min-size 64m //当当前aof文件超过多大时进行重写

重写的原理
当aof文件达到我们配置的两个约束的时候，redis会fork一个子进程，把当前内存中的数据再写一遍 。具体过程是这样的，redis fork一个子进程，去重写aof文件，那么在这个过程当中发生的数据操作会被放到一个重写缓存个当中去；当aof完成以后再把重写缓存的中的指令追加到aof文件当中去。

那么这个aof文件同步到磁盘的频率是怎么样的呢？
在redis配置文件里还有这样几个串串
#appendfsync always //总是
appendfsync everysec //每秒
#appendfsync no //从不（表示redis不主动去完成）
这个配置描述了aof文件同步到磁盘的时机 默认是每秒

---------------------------------------------------分割线----------
总结 ：两种DAO方式要根据自己的业务场景进行取舍