redis基础(二)持久化方式

持久化方式两种：
1.快照（snapshot），默认是此方式，保存的文件是rdb格式，所以也叫rdb方式。
生成方式有客户端方式（通过bgsave和save命令）或者服务器配置自动触发方式。
bgsave和save的区别：
bgsave命令会调用fork生成一个子进程，与父进程共享内存，如果没有对内存的写操作任务的情况下，子进程可以最大限度的利用内存生成快照，有写操作的时候父子线程会分享内存，也就是父进程用一部分内存来处理客户端请求执行写操作，而子线程用剩余部分内存来生成快照。自动触发方式也是使用的bgsave命令。
save只有一个主进程，由主进程生成快照，在此期间redis处于阻塞状态，不会响应客户端请求。










上图模拟断电后重启服务器查询为空就是rdb方式的弊端，因为上一次快照和下次快照中间有间隙，间隙时间断电会导致此时间段的数据丢失。

2.AOF(append only file)只追加日志。
AOF可以将所有客户端的写命令记录至日志文件中，做到了实时持久化。


win环境下redis目录有两个配置文件，一个windows.conf,一个windows-service.conf，对这两个文件的概念还是有点模糊，网上也没有精确的表述。据本人推测service.conf是系统默认的配置，windows.conf是自定义配置，其实在这任何一个文件中进行自定义配置都是可以的，前提是在开启服务器时要加载文件才能生效（已测试）。如果不加载任何一个配置文件，服务器默认启用初始化配置。

为了解决aof文件臃肿问题，可以使用AOF重写来减小aof文件体积，重写方式有两种：
1.客户端执行bgrewriteaof，此方式不会阻塞redis.
2.配置文件中配置自动触发，也相当于执行了bgrewriteaof命令。



重写不会读取旧的aof文件，而是将旧的aof文件进行了替换，流程如下：
1.调用fork生成子进程，子进程对快照中的数据进行解构，再解构后所得到的命令写入临时文件。
2.主进程继续处理客户端请求，照常把命令写入至aof文件，同时会将新的写命令(快照中未搜集的)进行缓存，写aof文件是为了保证重写失败后仍有完整的aof文件，缓存是为了保证上一次快照没搜集到的最新命令不会遗漏。
3.子进程完成写入命令至临时文件后，会发信号通知父进程，父进程再将缓存的命令也写入临时文件。
4.父进程对临时文件重命命替换掉之前的aof文件，然后继续进行常规的aof文件记录，直到下一次重写。
总结：rdb效率更高，但是安全性低,默认开启。aof安全性高，效率更低，默认关闭。两者可以混合使用，两者都开启情况下优先加载aof。