RDB 快照时运行修改数据吗

RDB 快照时修改数据过程

写时复制技术

RDB 的执行频率

增量快照

由于快照的频率不好把握，所以可以通过增量快照的方式解决全量快照的弊端。

增量快照：做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。

增量快照会带来额外的空间开销，因为需要额外的元数据信息去记录哪些数据被修改，这对于内存资源宝贵的 Redis 来说，有些得不偿失

AOF

1. AOF持久化(即Append Only File持久化)，以日志的形式记录服务器所处理的每一个写，删除操作，而查询操作不会记录。

2. AOF采用的是写后日志的方式，Redis先执行命令把数据写入内存，然后再记录日志到文件中。
 

如何开启AOF

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置文件中开启

1. 修改 appendonly yes 开启持久化

2. 修改 appendfilename " appendonly.aof" 指定生成文件名称

AOF 为什么要采用后写日志呢？

AOF采用的是 "写后日志"的方式，我们平时用的MySQL则采用的是 "写前日志"。

1. 可以避免出现记录错误命令的情况 。Redis在向AOF里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，若命令有错，并在记日志之后发生宕机，日志中就有可能记录了错误的命令，Redis在使用日志恢复数据时，就可能出错。

2. 它在命令执行后才记录日志 ，不会阻塞当前的写操作。

后写日志的弊端

后写日志主要有两个风险可能会发生：

1. 数据可能会丢失：如果 Redis 刚执行完命令，此时发生故障宕机，会导致这条命令存在丢失的风险。

2. 可能阻塞其他操作：AOF 日志其实也是在主线程中执行，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执 行。

AOF 的优缺点

优点

1. 数据安全

2. 通过append模式写文件，即使中途服务器宕机也不会破坏已经存在的内容，可以通过

redis-check-aof工I具解决数据一致性问题。

3. AOF 机制的rewrite模式。定期对AOF文件进行重写，以达到压缩的目的

缺点

1. AOF文件比RDB文件大，且恢复速度慢。

2. 数据集大的时候，比RDB启动效率低。

3. 运行效率没有RDB高

AOF 日志写回磁盘的策略

AOF 机制给我们提供了三个选择，也就是 AOF 配置项 appendfsync 的三个可选值

1. Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

2. Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

3. No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘；

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

其中，appendonly配置为yes，表示开启AOF持久化机制；appendfilename配置AOF文件名，默认为appendonly.aof；appendfsync配置为每秒同步一次，也可以根据需求修改为always或no。

2.在redis.conf配置文件中添加以下配置，表示启用混合持久化机制：

aof-use-rdb-preamble yes

1. 此配置表示在AOF文件开头加入RDB文件的内容，可以提高数据恢复的速度。

2. 修改完配置后，保存文件并重启Redis服务器使配置生效。