5：Redis持久化（AOF持久化方式 与持久化总结 ）
2021-04-07 本文已影响0人
_River_
1：针对RDB的弊端解决思路
RDB对于持久化来说最大的缺点是：
1：耗时，耗性能
2：不可控，容易丢失数据，服务器在发生故障时候会丢失数据。
解决方案：AOF
1：不写全数据，仅记录部分数据
2：降低区分数据是否改变的难度，改记录数据为记录操作过程
3：对所有操作均进行记录，排除丢失数据的风险
2：AOF概念
AOF(append only file)持久化：
以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。
与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
3：启动AOF相关配置
在redis.conf 里面有以下配置
具体配置解释：
1：开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no
2：AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename
3：AOF持久化文件保存路径只能与RDB持久化文件保持一致
dir path
4：AOF写数据策略，默认为everysec
appendfsync always|everysec|no
默认配置：
1：appendonly no
2：appendfilename "appendonly.aof"
3：dir ./
4：appendfsync everysec
AOF写数据三种策略(appendfsync)：
always(每次）：
每次写入操作均直接 经过 AOF缓冲池区 同步到AOF文件中；
数据零误差，性能较低，不建议使用。
everysec（每秒）：
数据先实时同步到AOF缓冲区
每秒将AOF缓冲区中的指令同步到AOF文件中，
在系统突然宕机的情况下丢失1秒内的数据
数据准确性较高，性能较高，建议使用，也是默认配置
no（系统控制）：由操作系统控制每次同步到AOF文件的周期
整体过程不可控
4：AOF的重写机制
1： 如果连续执行如下指令该如何处理？
2： 什么是AOF重写？
AOF重写只是AOF持久化中的一个优化策略
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。
AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。
简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。
AOF重写作用
1：降低磁盘占用量，提高磁盘利用率
2：提高持久化效率，降低持久化写时间，提高IO性能
3：降低数据恢复用:时间，提高数据恢复效率
3： AOF重写规则？
1：进程内具有时效性的数据，并且数据已超时将不再写入文件
2：非写入类的无效指令将被忽略，只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
3：对同一数据的多条写命令合并为一条命令
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
4：AOF重写方式？
1：手动重写：
bgrewriteaof
可以使用该命令马上进行触发
2：自动重写：
#AOF文件重写需要的最小的大小。就是说当AOF文件至少多大体积的时候在开始进行重写
auto-aof-rewrite-min-size size
#AOF文件增长率。当进行过了一次重写，下一次进行重写的时候看这个AOF文件的增长率
auto-aof-rewrite-percentage percentage
默认值
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100
使用info Persistence获取对应的参数
aof_current_size(当前AOF文件的大小)
aof_base_size (上一次操作或者重写后的AOF文件大小)
当条件满足下面其中一个条件时 可以触发自动重写
5：AOF重写流程图
1：always
每次写入操作均直接 经过 一个AOF缓存区 同步数据到 AOF文件中
2：everysec
每次写入操作 同步到数据到 一个AOF缓存区中
每秒 从AOF缓存区 同步数据到 AOF文件中
3：everysec 开启重写
1：每次写入操作 先同步到数据到
一个AOF缓存区中 以及 一个AOF重写缓存区中
2： 每秒 从AOF缓存区 同步数据到 AOF文件中
everysec 开启重写 完整逻辑（重点）
1、在重写模式下
2：父进程创建函数，同时创建 重写子进程，
3-1：将写命令 通过aof_buf缓存区 追加到现有的AOF文件中；即使AOF重写期间发生停机，也不会有任何数据丢失；
3-2：将写命令 追加到AOF重写缓存中。所有对数据库进行修改的命令都会被记录到AOF重写缓存中。
4：重写子进程在满足触发条件下完成对AOF文件进行重写
5-1：它重写完成后 会向父进程发送一个完成信号，父进程接到该完成信号之后，
5-2：将AOF重写缓存中的内容全部写入到新的AOF文件中；
5-3：对新的AOF文件覆盖原有的AOF文件。（aof_rewrite_buf 有新的命令 不担心丢失）
6：RDB与AOF区别
RDB 默认开启 config set save "" 进行关闭
AOF 默认关闭 config set appendonly yes 进行开启
启动优先级：Redis同时开启了RDB和AOF时，Redis重启
Redis先加载AOF进行数据恢复。降低丢失数据的量
那同时开启是 RDB 有什么作用?
全量备份，灾难恢复。
RDB与AOF的选择：
1： 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
AOF持久化策略使用everysecond，每秒钟fsync一次。
该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
2：如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，
阶段有效性数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
最终推荐：
同时开启RDB与AOF ：
AOF：作为普通重启使用
RDB：作为灾难恢复使用
参考技术文章：
https://www.cnblogs.com/songgj/p/9408784.html
http://blog.sina.com.cn/s/blog_a1e9c7910102vkdi.html
