redis的持久化策略

redis提供持久化策略，在适当的时机采用适当的手段把内存中的数据持久化到磁盘中，每次redis服务启动时，都可以把磁盘上的数据再次加载到内存中使用。

1. RDB策略（数据快照模式）：在指定时间间隔内，redis服务执行指定次数的写操作，会自动触发一次持久化操作。
   RDB策略是redis默认的持久化策略，redis服务开启时这种持久化策略就已经默认开启了。

   i. save <seconds> <changes>:配置持久化策略
   ii. dbfilename：redis RDB持久化数据存储的文件
   iii. dir：配置redis RDB持久化文件所在目录

   	优点：
   	1. 存储的文件是紧凑的
   	2. 适用于备份，方便恢复不同版本的数据
   	3. 适用于容灾恢复，备份文件可以在其他服务器恢复
   	4. 最大化了redis的性能，备份时启动的是子线程，父进程不需要执行IO操作
   	5. 数据保存比AOF快
   	
   	缺点:
   	1. 如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
   	2. 由于需要经常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

2. AOF策略（追加模式）：采用操作日志来记录每一次写操作，每次redis服务启动时，都会重新执行一遍操作日志中的指令。
   但是AOF效率低下，redis默认不开启AOF功能。

   i. appendonly：配置是否开启AOF策略。
   ii. appendfilename：配置操作日志文件

   优点:
   1. 使用AOF模式更加的灵活，因为可以有不同的fsync策略
   2. AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
   3. 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
   4. AOF包含一个又一个的操作命令，易于理解和解析
   
   缺点:
   1. 对于同样的数据集，AOF文件通常要大于RDB文件
   2. AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
   3. AOF通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）
   

总结：根据数据的特点来决定开启哪种持久化策略：一般情况下，开启RDB策略足够。

参考：https://blog.csdn.net/q649381130/article/details/79920277