redis的持久化策略

redis的持久化方式有俩种，持久化策略有4种：

• RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
• AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
• 如果只希望数据保存在内存中的话，俩种策略都可以关闭
• 也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据

RDB

RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。

优点

• 存储的文件是紧凑的
• 适合用于备份，方便恢复不同版本的数据
• 适合于容灾恢复，备份文件可以在其他服务器恢复
• 最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
• 数据保存比AOF要快

缺点

• 如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
• 由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。属于数据量大的时候，一个服务器不要部署多个Redis服务。

创建快照有以下5种形式：

1. 客户端发送BGSAVE指令，服务端会fork一条子线程将快照写入磁盘
2. 客户端发送SAVE指令，服务端在主线程进行写入动作。一般不常使用，一般在内存不够去执行BGSVAE的时候才用
3. 设置了SAVE配置项，如SAVE 300 100，那么当“300秒内有100次写入”时，Redus会自动触发BGSAVE命令。如果有多个配置项，任意一个满足，都会触发备份
4. Redis通过SHUTDOWN命令接收到关闭服务器的请求、或者TERM信号（linux 退出信号）时，会执行SAVE命令，这时候会阻塞所有客户端，不在执行客户端发送的任何命令
5. 当一个Redis服务器连接另外一个Redis服务器，并像对方发送SYNC命令开始一次复制操作时，如果主服务器目前没有在执行BGSAVE操作，或者主服务器刚刚执行完，那么主服务器就会执行GBSAVE

AOF(append only file)

AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行
一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写操作集。

优点
- 使用AOF模式更加的灵活，因为可以有不同的fsync策略（刷新策略通过参数appendfsync控制，有三个值：always、everysec、no，默认是everysec）
- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
- 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
- AOF包含一个又一个的操作命令，易于理解和解析

缺点

• 对于同样的数据集，AOF文件通常要大于RDB文件
• AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
• AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份），

以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用
是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定

AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

1）所有的写入命令会追加到aof_buf（缓冲区）中。
2）AOF缓冲区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

命令写入
AOF命令写入的内容直接是文本协议格式。例如set hello world这条命令，在AOF缓冲区会追加如下文本：
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

1）AOF为什么直接采用文本协议格式？可能的理由如下：
·文本协议具有很好的兼容性。
·开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
·文本协议具有可读性，方便直接修改和处理。

2）AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

文件同步
1.Redis提供了多种AOF缓冲区同步文件策略  由appendfsync控制 在redis.conf可以修改。

always 命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回
everysec 命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。
no  命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次

write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周
期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
·fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。

配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。

重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

重写后的AOF文件为什么可以变小？有如下原因：
1）进程内已经超时的数据不再写入文件。
2）旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
3）多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF
文件可以更快地被Redis加载。
AOF重写过程可以手动触发和自动触发：
·手动触发：直接调用bgrewriteaof命令。
·自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
  auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
  auto-aof-rewrite-percentage：代表当前AOF文件空
间

流程：执行AOF重写请求，判断系统是否有无子线程在做持久化操作。
1.如果当前进程正在执行AOF重写，请求不执行并返回。
如果当前进程正在执行bgsave操作，重写命令延迟bgsave完成之后再执行
2.父进程执行fork创建子进程，开销等同于bgsave过程。
3.1主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4.子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件
5.3）使用新AOF文件替换老文件，完成AOF重写。

重启加载
AOF和RDB文件都可以用于服务器重启时的数据恢复。
AOF持久化开启且存在AOF文件时，优先加载AOF文件
AOF关闭或者AOF文件不存在时，加载RDB文件
加载AOF/RDB文件成功后，Redis启动成功。
AOF/RDB文件存在错误时，Redis启动失败并打印错误信息

文件校验
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启