1.redis持久化
在客户端发布save的过程中有可能造成阻塞，如一千万条数据同时保存并生成二进制RDB文件的时候，此时就会延迟堵塞。
文件策略是如果存在老的RDB文件，会用新的文件替代老的文件如下图所示：
对于bgsave而言，它会利用linux中的fork（）函数生成一个redis的子进程(fast的意思是相对来说速度比较快，但是当量大的时候依旧有可能阻塞主线程),然后再生成RDB文件，并且将成功生成的消息（bgsave successfully）返回告诉主进程，并响应客户端如下图所示：
5.save与bgsave的对比：所说的阻塞对比当量小的时候几乎没区别
6.若客户端不发布save的命令，redis也可以进行保存的操作配置。不论是60秒发布10000条，还是300秒发布10条，还是900秒发布一条信息都会进行更新保存并生成RDB文件。利用的就是bgsave来保存生成，（但是这种操作也有不合适的弊端，就是文件写入过于频繁，60秒就需要更新10000条）
对于生成的RDB文件一般用dump.rdb的格式来保存。
最佳配置：
：当保存出错时是否停止写入
：是否要压缩文件，rdb文件会在主从之间进行拷贝，采用压缩的形式可以加快拷贝速度
：是否对rdb文件进行校验检验
· 
：文件名一般用端口号来区分
：一般情况下不选用根目录来保存，而是选择大的硬盘路径来保存
总结RDB：
1耗性能，耗时（对所有数据进行dump，其次写会消耗很多的cpu和内存（IO性能），是个on的过程（copy-on-write策略））
2不可控，丢失数据（定时保存或多或少会丢失一部分数据）
AOF：
AOF的三种策略：always，everysec，no
always：写的命令会进入到缓存区中，每条命令fsync到硬盘中生成AOF文件
everysec：写的命令会进入到缓存区中，每秒都会刷新fsync到硬盘中生成AOF文件（出现故障的时候有可能会丢失一秒的数据）
no：写的命令会进入到缓存区中，会根据不同的系统来选择写入还是不写入，不需要人为考虑，系统自动判断
一般情况下根据各方面权衡会默认选择使用everysec的方案
7.当高并发或者时间推移日志文件会变得冗余，很消耗内存，此时可以选择使用AOF重写，AOF重写可以减少硬盘的占用量，加速恢复速度，
AOF重写的两种实现方式：
1.bgrewriteaof：和bgsave类似
2.AOF重写配置
配置：no-appendfsync-on-rewrite :是否关闭重写
。。。。perscentage 100：表示增长率
RDB和AOF的取舍：
RDB：集中管理可以一次性写入大量，但不要太频繁，因为对机器内存cpu等影响比较大，
AOF：建议一直开着，也体现出redis持久化的特点，等到一定时间可以关闭，毕竟开缓存也需要一定的开销
集中管理利用fork（），但是也有可能出现内存爆满的情况
RDB：集中管理可以一次性写入大量，但不要太频繁，因为对机器内存cpu等影响比较大，
最佳策略：小分片：利用redis进行内存分配，每个内存分配最大4G，当然cpu的消耗也比较大
