redis数据持久化

Redis是基于内存的，如果不想办法将数据保存在硬盘上，一旦Redis重启(退出/故障)，内存的数据将会全部丢失。(业务库中缓存的数据 , 存储的一些重要的标签, 状态数据)
我们肯定不想Redis里头的数据由于某些故障全部丢失(导致所有请求都走MySQL)，即便发生了故障也希望可以将Redis原有的数据恢复过来，这就是持久化的作用。

• RDB(基于快照)，将某一时刻的内存中的所有数据保存到一个RDB文件中（二进制带压缩）
• AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。

1.RDB(快照持久化)

RDB持久化可以手动执行，也可以根据服务器配置定期执行。RDB持久化所生成的RDB文件是一个经过压缩的二进制文件，Redis可以通过这个文件还原数据库的数据。

有两个命令可以生成RDB文件：

• SAVE会阻塞Redis服务器进程，服务器不能接收任何请求，直到RDB文件创建完毕为止
• BGSAVE创建（fork）出一个子进程，由子进程来负责创建RDB文件，服务器进程可以继续接收请求。
  Redis服务器在启动的时候，如果发现有RDB文件，就会自动载入RDB文件(不需要人工干预)
  服务器在载入RDB文件期间，会处于阻塞状态，直到载入工作完成。
  除了手动调用SAVE或者BGSAVE命令生成RDB文件之外，我们可以使用配置的方式来定期执行：
  在默认的配置下，如果以下的条件被触发，就会执行BGSAVE命令

示例：

----------rdb快照------------
save 900 1      前面是时间   后面是操作次数
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes  
当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据
rdbcompression yes  
对于存储到磁盘中的快照，可以设置是否进行压缩存储。      
如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。  
rdbchecksum yes
默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，
但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。  
dbfilename dump.rdb
设置快照的文件名，默认是 dump.rdb  
dir ./
设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。
使用上面的 dbfilename 作为保存的文件名。

手动触发持久化

save    他会阻塞  ==》 在保存dump.rdb文件完成之前，不能在客户端做任何的操作
bgsave  后台取保存  ==》 在后台开一个线程，单独的为你保存dump.rdb这个文件
CONFIG GET dir   数据恢复只需要将指定的dump.rdb文件导入到安装目录下即可

2.AOF(文件追加)

示例：

APPEND ONLY MODE
appendonly no   
默认该模式关闭

appendfilename "appendonly.aof"
aof文件名，默认是"appendonly.aof"


# appendfsync always
appendfsync everysec
# appendfsync no
aof持久化策略的配置；
no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快；
always表示每次写入都执行fsync，以保证数据同步到磁盘； 最多丢一条数据
everysec表示每秒执行一次fsync，可能会导致丢失这1s数据

no-appendfsync-on-rewrite：
在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，
执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。
如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，
这样对持久化特性来说这是更安全的选择。   
设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，
默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。

auto-aof-rewrite-percentage 100
默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少
进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。
当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb
设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

aof-load-truncated yes
aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。
重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，
出现这种现象  redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。
如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。

AOF是通过保存Redis服务器所执行的写命令来记录数据库的数据的。

比如说我们对空白的数据库执行以下写命令：
redis> SET meg "hello"
OK

redis> SADD fruits "apple" "banana" "cherry"
(integer) 3

redis> RPUSH numbers 128 256 512
(integer) 3 
 
Redis会产生以下内容的AOF文件

3.AOF重写（BGREWRITEAOF命令）

数据库经历了如下操作
set a 1
set a 2
set a 3
set a 4
set a 5
set a 6
set a 7
set a 8
那么，aof中的记录也会有上述的8条
然而，数据库中的最终状态仅仅是：  a  -> 8
那么，aof中的大量记录都是冗余无效的，可以执行rewrite操作来精简体积提高效率
==>  rewrite aof
set a 8
可以通过配置让redis自动定期对aof文件进行重写
也可以用命令来触发aof重写：  BGREWRITEAOF

4.持久化方式的选择

RDB和AOF并不互斥，它俩可以同时使用。

• RDB的优点：载入时恢复数据快、文件体积小。
• RDB的缺点：会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)
• AOF的优点：丢失数据少(默认配置只丢失一秒的数据)。
• AOF的缺点：恢复数据相对较慢，文件体积大
  如果Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)

5.相关参数

redis持久化，两种方式
1、rdb快照方式
2、aof日志方式
----------rdb快照------------
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/rdb/

-----------Aof的配置-----------
appendonly no # 是否打开 aof日志功能

appendfsync always #每一个命令都立即同步到aof，安全速度慢
appendfsync everysec
appendfsync no #写入工作交给操作系统，由操作系统判断缓冲区大小，统一写入到aof  同步频率低，速度快


no-appendfsync-on-rewrite yes #正在导出rdb快照的时候不要写aof
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb