Redis（一）持久化：快照和AOF

一、持久化

Redis持久化提供两种方式：快照和AOF。

1.快照（snapshotting）

将Redis内存中的数据在同一时刻（可以配置，比如300秒内有10个key发生了变化）的副本写到磁盘
save 900 1 #900秒 1个修改
save 300 10 #300秒 10个更新
save 60 10000 #60秒 10000个更新

Redis触发快照有5种方式：

A.客户端执行BGSAVE命令，Redis fork一个子进程来将快照写到磁盘，如果Redis内存存储几十G数据时可能需要暂停几ms到几百ms不等（视服务器硬件而定）来fork子进程，在子进程进行BGSAVE操作时，Redis主进程照样可以处理客户端的命令，BGSAVE不会停住阻塞Redis进程。

如看下面
Redis主进程
2251 www       20   0  130m 7920 1484 S  0.0  0.8   0:00.63 redis-server
Redis的日志:
2251:M 23 Dec 18:54:05.021 * 10 changes in 300 seconds. Saving...
2251:M 23 Dec 18:54:05.048 * Background saving started by pid 2286
2286:C 23 Dec 18:54:05.082 * DB saved on disk
2286:C 23 Dec 18:54:05.083 * RDB: 6 MB of memory used by copy-on-write
2251:M 23 Dec 18:54:05.149 * Background saving terminated with success
可以看出，从上次快照完成到现在的300秒内有10个key发生变化，Redis主进程fork子进程2286进行BGSAVE的快照操作。

B.客户端执行SAVE命令，Redis会停住客户端的所有请求命令，直到快照完成。

C.当我们配置了save配置行，只要其中一个save配置行条件满足，则会启动快照操作，快照操作是BGSAVE模式的，所以Redis不会停下来，而会继续处理客户的请求。

D.Redis接收到SHUTDOWN命令时，它启动SAVE模式的快照操作，所有客户的命令请求会被停住阻塞，快照完成后关闭Redis。
如：
客户端
127.0.0.1:6379> shutdown
not connected>
Redis服务端
2901:M 23 Dec 04:06:13.609 # User requested shutdown...
2901:M 23 Dec 04:06:13.609 * Saving the final RDB snapshot before exiting.
2901:M 23 Dec 04:06:13.613 * DB saved on disk

2901:M 23 Dec 04:06:13.613 # Redis is now ready to exit, bye bye...

E.从节点Redis(slave)连接上主节点(master)并发送SYNC命令（请求master同步数据命令）复制数据，master会启动BGSAVE模式的快照操作。

2.AOF（append-only file，追加文件）

每次执行写命令时都将写命令写到磁盘
可以通过配置
appendonly yes|no
设置yes从而开户AOF持久化的特性。
当然了，写命令不会直接写到磁盘，写命令会首先写到缓冲区，到了触发点时才能将缓冲区的写操作命令写到AOF文件结尾
触发AOF持久化的频率可以通过下面三种之一来配置
appendfsync always #每次执行写命令，也将写到AOF文件，这使得Redis性能低下，转盘式磁盘200次/秒写操作，固态磁盘几万次/秒操作
appendfsync everysec    #每秒同步一次写操作到AOF文件，这样可以使得即使Redis崩溃了，Redis的丢失数据也是在1秒之内或者无丢失。
appendfsync no     #让操作系统决定何时将写操作同步到AOF文件，这个配置选项，
                                  #由于 我们无法控制何时将缓冲区的写命令同步到AOF文件，可能导致缓冲区溢满导致写操作无法执行，造成Redis阻塞。
随着写命令的不断累加，会导致AOF不断地增大，Redis提供后台重写AOF(BGREWRITEAOF)，BGREWRITEAOF类似快照持久化的BGSAVE，也会fork一个子进程对AOF文件进行重写，重写完AOF文件后，需要删除旧的AOFT文件，这时Redis主进程会被阻塞，直到旧的AOF被删除才能使用新重写的AOF文件，如果旧的AOF过大的话可能会造成Redis数秒的阻塞时长。
BGREWRITEAOF这个特性可能通过下面配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
当AOF文件比上次重写后的AOF文件增大了100%并且AOF文件大于64mb时会触发AOF的后台重写操作BGREWRITEAOF。

介绍下下面配置
no-appendfsync-on-rewrite yes|no #默认情况下设置为no
当AOF进行BGREWRITEAOF操作，Redis的主进程不会进行AOF持久化(是指设置为yes的情况下)，这样在重写AOF期间Redis崩溃了，会造成这段时间写操作的数据丢失，所以谨慎使用。