Redis系列(四)--持久化

持久化就是将数据的更新异步的保存到磁盘中

持久化方式：

　　1、快照：某个时间点数据的备份 MySQL dump、Redis RDB

　　2、写日志：MySQL BinLog、HBASE Hlog、Redis AOF

只针对Redis两种持久化方式进行介绍，RDB和AOF可以使用一种、两种，甚至都不使用

持久化配置选项：

#RDB持久化选项
#save 900 1                                //900s有一次写入
#save 300 10                            　　//300s有10次写入
#save 60 10000                            //60s中有10000次写入
stop-writes-on-bgsave-error no            //创建快照失败后是否继续执行写命令
rdbcompression yes                        //知否对快照文件进行压缩
dbfilename "dump_6379.rdb"                //快照文件名

#AOF持久化选项
appendonly yes                            //是否使用AOF持久化
appendfilename "appendonly.aof"            //AOF文件名称
appendfsync everysec                    　　//多久将写入内容同步到硬盘
no-appendfsync-on-rewrite no            　　//对AOF进行重写时，是否执行同步操作
auto-aof-rewrite-percentage 100            //多久执行一次AOF压缩
auto-aof-rewrite-min-size 64mb

dir "/var/local/redis/data"                //共享选项，决定了RDB和AOF文件的保存位置

RDB

工作原理：快照snapshotting

　　Redis创建RDB文件以二进制的形式保存在磁盘中，将存在于某一时刻的所有数据写入磁盘，然后就可以通过这个RDB文件恢复数据（启动载入）

在创建快照之后，用户可以对快照进行备份，复制到其他服务器从而创建具有相同数据的服务器副本。

创建RDB文件的方式：

1、save（同步）：可能会发生阻塞，数据量很大时，如果存在老文件，会发生替换

2、bgsave（异步）：通过fork()创建一个子进程去生成RDB文件，fork()执行很快的，极小的情况下才会发生阻塞

3、自动：触发某些条件，内部执行了bgsave生成RDB文件

当满足任意条件的时候就会触发BGSAVE命令

#save 900 1                                //900s有一次写入
#save 300 10                            　　//300s有10次写入
#save 60 10000                            //60s中有10000次写入

对默认配置进行优化修改：右边是修改后

save 900 1    　　　　　　　　#save 900 1

save 300 10    　　　　　　  #save 300 10

save 60 10000    　　　　　　#save 60 10000

dbfilename dump.rdb    　　dbfilename dump-${port}.rdb

dir ./    　　　　　　　　　　dir /bigdiskpath

4、主从复制，全量复制也会产生RDB文件

5、debug reload debug级别的重启，不需要将内存清空

6、shutdown

缺点：

　　1、耗时（将内存中数据进行dump 时间复杂度O(N)）

　　2、消耗内存：fork()，copy-on-write策略

　　3、Disk I/O：IO性能

　　4、不可控，丢失数据，T3到T4之间数据丢失了，或者使用save、bgsave的定时任务，存在同样的问题

异常场景：

　　T1 执行多个写命令

　　T2 满足RDB自动创建的条件

　　T3 再次执行多个写命令

　　T4 宕机

这时候就会丢失T2到T4之间的数据，所以，RBD方式只适用于哪些即使丢失一部分数据也不会造成问题的应用程序

AOF

　　AOF持久化就是将被执行的写命令写到AOF文件的末尾，一次来记录数据发生的变化。

策略：

1、always：

2、everysec：一般使用这个

3、no：OS控制

　　我们使用everysec的策略，使我们丢失数据的时间窗口降低至1s（甚至不丢失数据），但是随着Redi不断运行，aof文件的体积会变得很大，甚

至会用完磁盘空间，而且文件体积过大，在进行还原操作的时间会很长。

　　为了解决AOF文件体积增大的问题，出现了AOF重写

AOF重写：

　　为了减少磁盘占用量、加速恢复速度

原生AOF    　　　　    AOF重写

set hello world        set hello hehe
set hello java         set counter 2
set hello hehe        rpush mylist a b c
incr counter
incr counter
rpush mylist a
rpush mylist b
rpush mylist c

删除过期数据

AOF重写实现方式：

　　1、bgrewriteaof命令：fork()出一个子进程，然后通过内存进行AOF重写出一个AOF文件,而不是通过原来的AOF文件去重写

　　2、AOF重写配置

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

通过上面两个参数，能够自动执行BGREWRITEAOF。

上面100和64mb代表着，当AOF文件体积大于64MB，并且AOF文件的体积比上次重写之后的体积打了至少100%的时候，将执行BGREWRITEAOF命令

持久化方式的选择：

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	轻	重

RDB最佳策略：

　　1、最好选择把RDB"关闭"，主从复制的时候需要主节点的RDB文件传给子节点

　　2、集中管理：按天、星期等备份是个不错的选择，文件比较小

　　3、主从，从开

　　4、注意save发生的频率不要很频繁

AOF最佳策略：

　　1、"开"：缓存和存储，只是进行缓存的场景是可以关闭的

　　2、AOF重写集中管理：单机多部署的时候，针对集中发生fork，所以一个机器70%的内存分配给Redis

　　3、同步频率为everysec

最佳策略：

　　1、小分片：通过maxmemory进行设置，例如最大内存设置4G

　　2、缓存或存储

　　3、监控（硬盘、内存、负载、网络）

　　4、足够内存

fork操作：

　　1、是同步操作，会阻塞Redis

　　2、和内存量相关：内存越大，耗时越大（物理机和虚拟机也有差别，物理机性能更好）

　　3、info:latest_fork_usec 查看fork执行时间

改善fork操作：

　　1、优先使用物理机或支持高效fork操作的虚拟技术

　　2、设置Redis的最大使用内存：maxmemory

　　3、合理配置Linux内存分配策略：vm.overcommit_memory=1 默认0

　　4、降低fork频率：放宽AOF重写的触发规则，减少不必要的全量复制

fork产生的子进程开销和优化：

1、CPU：

　　开销：RDB和AOF文件产生，属于CPU密集型操作

　　优化：不做CPU绑定，不和CPU密集型部署

2、内存

　　开销：fork产生子进程内存开销，copy-on-write（当父进程有写操作时，会产生一个副本，这时候才会消耗较多内存）

3、硬盘

　　开销：AOF和RDB文件的写入，可以结合iostat，iotop分析

优化：

　　1).不要和存储服务、消息队列这种高负载服务部署在一起

　　2).no-appendfsync-on-rewrite = yes

　　3).根据写入量决定磁盘类型：例如使用机械硬盘

　　4).单机多部署的时候持久化文件目录可以分盘