Redis持久化方式：RDB/AOF

一. Redis持久化

所有的数据都存储在内存中，为了保证Redis在重启之后仍然能保证数据不丢失，那么就需要将数据从内存同步到硬盘上，这个过程就叫做持久化操作。

二. Redis持久化操作的方式

[1]RDB快照持久化

生成RDB文件的3种方式：save同步、bgsave异步、自动
(1)save：调用save的进程阻塞，直到RDB文件创建完毕位置，在阻塞期间服务器进程不能处理任何客户端的命令请求。

(2)bgsave：调用bgsave的进程立即返回，并派生出子进程，由子进程负责创建RDB文件，父进程继续处理命令请求

(3) Redis服务器自动载入RDB文件
RDB文件的载入工作是在服务器启动时自动执行的，即只要服务器在启动时检测到RDB文件存在，就会自动载入RDB文件，在载入过程中，服务器处于阻塞状态，直到载入工作完成。

---

配置save选项，让服务器每隔一段时间自动执行一次bgsave命令
    每隔N分钟或N次写操作，从内存dump数据形成rdb文件，压缩后，放在备份目录 。
注意：红色部分可以通过参数来配置

[root@localhost redis] cd /usr/local/redis/
[root@localhost redis] vi redis.conf 
save 900 1  # 每900s至少有1个key发生变化，会持久化1次(即向硬盘写一次)
save 300 10 # 每300s至少有10个key发生变化，会持久化1次(即向硬盘写一次)
save 60 10000 # 每60s至少有10000个key发生变化，会持久化1次(即向硬盘写一次)

stop-write-on-bgsave-error yes   #使用LZF压缩rdb文件
rdbcompression yes  # 存储和加载rdb文件时校验

dbfilename dump.rdb # 设置rdb文件名
dir ./ # 设置工作目录，rdb文件会写入该目录

优势：因为RDB保存的是快照，因此在进行恢复时直接将快照加载到内存即可
劣势：
在两个保存点之间，如果断电，将会丢失保存点之间更新的数据—>出于对持久化更精细的要求，redis添加了aof方式

总结：RDB方式适合大规模的数据恢复 && 对数据完整性和一致性要求不高(宕机会丢失数据)

---

[2]AOF方式

1. 原理：AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的
2. AOF持久化的实现
(1)命令追加
(2)AOF文件的写入
    ①在现代操作系统中，write函数将数据写入到文件的时候，操作系统通常会将写入数据暂时保存在内存缓冲区中，等到缓冲区被填满，才真正的将缓冲区中的数据写入到AOF文件中；
    ②这种做法带来了安全性问题，因为如果计算机发生停机，那么保存在内存缓冲区中的数据将会丢失；
    ③为此，系统提供了fsync和fdatasync两个同步函数，它可以强制让操作系统立即将缓冲区中的数据写入到硬盘，从而确保写入数据的安全性。
(3)AOF文件的同步：服务器通过配置appendfsync参数来决定AOF持久化功能的效率和安全性

appendfsync参数
always	每个命令都同步到aof中	只会丢失一个事件循环中所产生的命令数据	写入AOF文件速度最慢，最安全
everysec	每秒对AOF进行一次同步	只丢失一秒钟的命令数据	中立
no	对AOF同步时间you操作系统控制		单次同步时间最长，最不安全

3. 优点：相比RDB方式，更加安全
4. 缺点：文件更大，运行效率慢
5. AOF rewrite重写：BGREWRITEAOF
(1)因为AOF总是以追加的方式写入AOF文件，势必将导致AOF文件过大：体积过大将会影响Redis服务器、整个宿主计算机，并且导致AOF文件还原事件过长。为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写功能
(2)实现原理：不需要对现有AOF文件进行任何读取、分析或者写入操作，而是通过读取服务器当前数据库状态来实现。
6. AOF文件的载入与数据还原
Redis服务器只需要读取并重新执行一遍AOF文件中保存的写命令，就可以恢复服务器关闭之前的数据库状态。Redis读取AOF文件并还原数据库状态的详细步骤如下：
(1)创建一个不带网络连接的为客户端来执行AOF文件保存的写命令
(2)从AOF文件中分析并读取每一条写命令，直到写命令都被处理完毕为止。

Q：在dump rdb过程中，如果aof停止同步，会不会丢失？
答：不会，所有的操作缓存在内存的队列里，dump完成后统一操作

[root@localhost redis] cd /usr/local/redis/
[root@localhost redis] vi redis.conf 
	appendonly no  # 是否打开AOF方式
	appendfilename "appendonly.aof" # 保存的文件名

	# 3种同步的策略
	# appendfsync always   # 每个命令都同步到aof中，速度最慢，最安全
	appendfsync everysec   # 每秒
	# appendfsync no	   # 写入工作交给操作系统
	
	no-appendfsync-on-rewrite no # 正在导出rdb快照时，要不要停止同步aof
	
	auto-aof-rewrite-percentage 100 # aof文件大小比起上次重写时的大小，增长率100%时重写
	auto-aof-rewrite-min-size 64mb # aof文件至少超过64M时，重写

三. 总结一下RDB和AOF

① 如果非常在意数据，又希望快速的恢复数据，可以简单的使用RDB。
② 只做缓存：如果只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
③ 同时开启两种持久化方式：
I、同时开启优先载入AOF文件来恢复原始的数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
II、RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件

实战：aof恢复、rdb服务器之间的迁移

Q1：如果在客户端程序中不小心执行了flushall清空了数据库应该怎么补救？

1. 一般情况下使用aof文件进行恢复数据库，但是aof存在被重写的可能，导致aof文件为空，因此：客户端程序应立即执行shutdown nosave(表示立即关闭服务器并且不重写aof)
2. 使用aof文件进行恢复数据库：将aof文件中的flushall命令进行删除，然后重启服务器。(因为服务器重启后，会自动加载aof文件，所以加载完成后服务器状态被恢复到执行flushall之前)

Q2：rdb服务期间迁移，即将一个Redis服务器1产生的.rdb文件，拷贝走，然后重启另一台服务器2加载.rdb文件，使得服务器2中的数据与服务器1中的数据一样。

1. 注意，很容易犯的错误：在拷贝服务器1产生的.rdb文件时，服务器1必须是关闭的，否则拷贝的.rdb文件不能用于数据库的迁移。
2. 将服务器1产生的.rdb文件拷贝走之后，在服务器2中配置redis.conf文件，便可以使用.rdb文件进行恢复

RDB和AOF对比、抉择