11/6笔记 补充（Redis持久化，RDB&&AOF）

11/6补充笔记

修改redis-6379.conf里面的save10秒2个数据发生改变 (save 10 2)

修改一次数据不发生改变，修改2次数据才发生改变

继续修改数据，发现还是一样的规律

增删该都发生变化，除了查以外。

save配置原理

返回结果，要对数据产生影响，数据发生了变化，或者变量达到设置要求，rdb才会发生变化。save配置要根据真实场景进行设置，否则性能可能出现问题，save配置后执行的是bgsave操作。

RDB2种启动方式对比

save指令在读写的过程中是同步的，而不敢save是异步的，save指令会阻塞客服端，bgsave读写的过程是异步的，会创建子线程(相当于启动了新进程)，不会造成客服端堵塞，但会造成额外消耗内存。

rdb特殊启动指令

服务器运行过程中重启

debug reload

关闭服务器是指定保存数据

shutdown save(不管是够开启，自动执行bgsave)

RDB优点与缺点

优点:

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每2小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。RDB恢复数据远远快于AOF的方式。

缺点:

RDB方式数据没办法做到实时持久化/秒级持久化,可能保存的数据不是很完整。因为bgsave每次运行都要执行fork操作创建子进程，会额外消耗性能，频繁执行成本过高。RDB文件使用特定二进制格式保存，Redis版本更新过程中有多个格式的RDB版本，存在老版本Redis服务数据格式无法兼容新版RDB格式的问题。

AOF

使用AOF的原因:针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

概念

AOF（append only file）持久化：以日志的方式记录数据产生的过程(每次写入时命令)， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据三种策略(appendfsync)

always(每次),每次把写入操作同步到AOF文件中,数据完整,性能较低.

everysec(每秒),每秒将缓冲区同步到AOF文件中,数据准确性和性能较高,一般都是使用这个指令,也是默认配置

no(系统控制),由操作系统控制每次同步到AOF中,整体不可控

实操:

配置:appendfilename配置为appendonly.aof,如果是多端口号的话,建议配置为appendonly-端口号.aof

1.进入conf目录配置redis-6379的conf文件

2.添加以下命令,开启持久化功能(appendonly yes|no),配置写数据策略(appendfsync always |everysec|no)

3.先杀死原来的服务进程,再重新用配置文件启动

4.进入data,查看文档是否多了一个aof的文件

5.添加数据发现文件变大了

6.在使用everysec指令,重启服务端,在修改数据之前查看文件大小

7.在写入数据之后,查看文件大小,和cat 文件.aof日志,发现修改数据日志成功

AOF重写

随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

目的:AOF重写节省了文件占用空间，提高数据恢复效率,更小的AOF 文件可以更快地被Redis加载.

AOF重写方式:手动和自动

手动:bgrewriteaof(后台重新写入aof)

自动: auto-aof-rewrite-min-size size

    `auto-aof-rewrite-percentage` *percentage*

修改配置文件

启动客服端修改数据

查看文件和查看aof文档数据

修改之后,启动bgrewriteaof会出现以下提示

再次查看文件大小明显变小了

当我查看aof数据过程的时候是乱码,反正文件是被压缩了.

AOF手动重写 :bgrewriteaof指令工作原理

与bgsave指令相似,首先也是发送指令(控制台会反馈Background append only file rewriting started),调用fork函数生成子进程,重写.aof文件,返回消息.

AOF自动重写

自动重写触发条件设置 auto-aof-rewrite-min-size size自动重写最小体积,默认为64MB。

​ auto-aof-rewrite-percentage percent代表当前AOF文件空间 和上一次重写后AOF文件空间的比值。

aof_current_size AOF文件空间 aof_base_size上一次重写后AOF文件空间

自动重写触发时机

aof_current_size>auto-aof-rewrite-min-size &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage

在客服端输入info,可以看到 Persistence(持久化),关于持久化的东西,

AOF重写流程

RDB与AOF区别

RDB产生的文件紧凑压缩比更高，占用储存空间小，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，储存速度很慢，可能会丢失数据，RDB在消耗资源是重量级的，相对于AOF启动优先级很低。

AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。由于体积很大，所以占用的储存空间很大，与RDB相比，是相反的，占用的储存空间很大，存储速度很快，恢复的速度比较慢，因为是记录的数据的储存过程，经过重写之后会变小，AOF在消耗资源方面是轻量级的，在不同的场景更改策略可以提高数据的安全性。

RDB与AOF的选者

对数据的过程很敏感，而且不要求恢复速度的话，建议使用AOF，

对数据要求完整性，建议使用RDB持久化方案，切恢复速度很快。

如果能承受数分钟以内的数据丢失，且追求恢复速度，选用RDB

如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

或者两者同时启用，优先使用AOF恢复数据，降低数据丢失的量。

持久化应用场景

应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计，应用于具有操作先后顺序的数据控制，应用于最新消息展示，应用于控制黑名单设定的服务控制，应用于计数器组合排序功能对应的排名。