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信号时，会执行SAVE命令，这时候会阻塞所有客户端，不在执行客户端发送的任何命令
5. 当一个Redis服务器连接另外一个Redis服务器，并像对方发送SYNC命令开始一次复制操作时，如果主服务器目前没有在执行BGSAVE操作，或者主服务器刚刚执行完，那么主服务器就会执行GBSAVE

AOF(append only file)

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

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

缺点

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