持久化

RDB

1.(snapshoting 快照)  创建快照存储内存中某时间点上的副本。

2.失败时的情况

　　例如：redis里目前有10GB数据，上一次快照在下午2：35 开始创建，并且创建成功。下午3：06再次创建快照，并且在下午3:08创建完毕前，有35个键更新了。

　　a)如果3:06到3:08之间系统发生崩溃，导致快照创建失败，那么2：35之后全部数据丢失。

　　b)如果在3:08创建快照成功后，系统本快，则3:06后更新的35个键丢失

　　注意：快照是以开始创建快照时内存中数据为基础创建的

3.什么时候会创建快照

　　a)BGSAVE命令 ，redis会fork子进程负责将快照写入硬盘，父进程继续处理请求。

　　b)SAVE命令 ，会阻塞redis服务器直到快照完成。此命令不常用，在内存不足时或者阻塞redis服务也没关系时可以使用。

　　c) 配置save配置项时，如save 60 1000  （60秒内有1000次写入）自动触发BGSAVE

　　d)SHOTDOWN 命令 关闭服务器时，或者接收到标准TREM信号时（？）执行SAVE命令，阻塞所有客户端，不再执行客户端发来的命令，SAVE结束后关闭服务器

　　d)当一个服务器连接另一个服务器，并向对方发送SYNC命令时开始一次复制操作时，如果主服务器没有执行BGSAVE，或并非刚执行过BGSAVE就会执行BGSAVE。

4. 快照时发生系统奔溃会丢失数据如果不能接受这些丢失则应使用AOF持久化方式

　　当redis数据量只有几个GB时候，使用快照保存数据没有问题。redis创建子进程将数据保存在硬盘里，生成快照需要的时间比读这句话所需要时间还要短。但是如果数据量达到几十个GB，并且剩余内存不多，或redis运行在虚拟机中，那么BGSAVE可能导致系统长时间停顿，也可能引发系统大量会用虚拟内存，导致redis性能降低。

　　快照消耗时间要根据redis服务运行环境进行评估

AOF 只追加文件 append-only file

1.AOF持久化会将被执行的写命令写到AOF文件的末尾

　　配置 appendfsync 

　　always 每个命令都写入，影响性能。收到磁盘性能限制：转盘式每秒大概处理200个写命令。固态硬盘：每秒大概几万个写命令 此命令使得redis每次写入一个命令，而不和其他选项一样一次写入多个命令，导致固态硬盘寿命从几年降低到几个月

　　everysec 每秒执行同步 和不适用任何持久化特性的性能相差无几 丢失最多一秒内的数据 

　　no 系统决定AOF文件同步时间。一般不会对性能产生影响；不推荐使用，原因1系统奔溃导致不定量数据丢失。2.如果应判处李写入操作不够快，缓冲区被等待写入硬盘的数据填满时，redis写入被阻塞，导致处理请求变慢。

2.AOF 文件重写/压缩

　　1)为什么要重写压缩？1.防止AOF文件过大，占用磁盘空间。2.AOF文件过大，还原操作执行时间会更长。

　　2)BGREWRITEAOF命令

　　    作用：移除AOF文件中的冗余命令来重写AOF文件。

　　    工作原理：和BGSAVE类似，创建子进程，由子进程负责AOF文件重写。所以快照持久化因为创建子进程导致的性能问题和内存占用问题，在AOF中也会存在。跟糟糕的时AOF文件更可能会比快照文件大几倍，所以AOF重写并删除旧AOF文件时，删除几十G的AOF文件可能导致系统挂起（hang）数秒

　　   配置：auo-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项自动执行BGREWRITEAOF命令 

　　　　auo-aof-rewrite-percentage  100   auto-aof-rewrite-min-size  64m 并启用AOF持久化，当AOF文件体积大于64M并且文件体积比上次重写后增大至少一倍执行BGREWRITEAOF命令 通过auo-aof-rewrite-percentage  配置大于100 控制AOF更大时在进行重写压缩

配置

RDB:

save 60 1000

stop-write-on-bgsave-error no

rdbcompression yes

dbfilename dump.rdb

AOF:

appendonly on

appendfsync everysec

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64m