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的消耗也比较大