redis学习2-redis.conf和redis持久化

redis的持久化：rdb 和 aof

RDB： redis database

指定时间间隔内将内存中的数据集快照写入磁盘。
RDB是整个内存的压缩过的snapshot，RDB的数据结构，可以配置符合的快照触发条件。
默认出场恢复设置：
1分钟内改了1万次
5分钟内改了10次
15分钟内改了1次

如果想要禁用RDB的话，可以不用save ，或者save “”。

优势：

• 适合大规模的数据恢复
• 对数据的完整性和一致性要求不高（可能会丢失最后一次快照修改的数据）
• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑内存空间

总结：

• RDB是一个非常紧凑的文件
• RDB在保存RDB文件时父进程唯一要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他的io操作，所有RDB持久化方法可以最大化redis的性能
• 缺点1：数据丢失风险大
• 缺点2：RDB需要经常fork子进程来保存数据到硬盘，当数据集比较大的时候，fork的过程非常耗时，可能会导致redis在一些毫秒级不能响应客户端的请求

AOF：append only file

AOF append only file

AOF 是以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来，只许追加文件但不可以改写文件，redis启动之初会读取文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF 保存的是appendonly.aof 文件

AOF的配置策略

appendonly yes
appendfilename
appendsync ：

• Always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
• Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
• no ：不同步

Rewrite

是什么 ：AOF采用文件追加的方式，文件会越来越大，为避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgwirteaof
重写原理：AOF文件持续增加而过大时，会fork一条新进程来将文件重写，遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

触发机制： redis会记录上次重写AOF大小，默认配置是当AOF文件大小是上次rewirte后大小的一倍切文件大于64m时触发。

优势

• appendfsync always：同步持久化，每次发生的数据变更都会被记录记录到磁盘，性能较差但数据完整性比较好。
• appendfsync everysec ：异步操作，每秒记录，如果一秒宕机，有数据丢失。
• appendfsync no：从不同步

劣势

• 相同数据集的数据而言 aof文件要远远大于rdb文件，恢复速度慢于rdb
• aof（逐条恢复）运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

总结

• AOF文件时一个只进行追加的日志文件
• Redis可以在AOF文件体积变得过大时候，自动的再后台对AOF进行重写
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB

如何选择使用AOF还是RDB？

• RDB持久化方式能够在指定的间隔时间内对数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重写执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，reids还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存：如果只希望数据在服务器运行时候存在，可以不用任何持久化方式
• 同时开启两种持久化方式：
  在这种情况下，redis重启时候会优先加载AOF文件来恢复原始的数据，因为通常情况下AOF文件保存的数据集要比rdb文件保存的数据集要完整。
  rdb数据不实时，同时使用两者时数据库重启只会找aof文件，那要不要只使用aof持久呢？建议不要，因为rdb更适合用于备份数据库（aof在不断变化不好备份），快速重启，而且不会有aof可能潜在的bug，留着作为万一的替补手段。

#####性能建议：