Redis两种持久化机制

数据从内存持久化到磁盘的流程

1.客户端发起数据写请求
2.redis端根据写请求对内存中的数据进行相应的修改
3.redis发起write的系统调用，内存数据发送到内存缓冲区
4.操作系统将数据写入磁盘buffer
5.磁盘控制器将磁盘buffer中的数据写入到物理介质

但是，持久化的过程中也可能发生异常

当前三步完成后，如果redis宕机，但操作系统运行正常，那么数据也是可以持久化成功的
当前三步完成后，如果redis和操作系统都发生了异常，那么持久化就很有可能失败
当前五步完成后，说明持久化已经完成了，即使这时操作系统和redis都发生异常，持久化也是成功的

Redis默认配置文件

Redis的默认配置文件为redis.conf，通常放在redis的安装主目录中

~]$ grep '^[^#].*$' redis.conf
daemonize no # 是否将redis以后台运行的方式运行，默认为no；
pidfile /var/run/redis.pid # daemonize设置为yes时，会将pid写入/var/run/redis.pid
port 6379 # 监听的端口，也可以配置绑定的ip，默认是注释的，可以配置成特定ip然后去掉注释
tcp-backlog 511 # 默认已配置，确定成功建立连接的socket连接数，不能大于/proc/sys/net/core/somaxconn
				# 系统默认128，因此需要参考两者进行配置，并发大的话，建议设置成2048
timeout 0 # redis的socket连接的超时时间，单位为秒，0表示不超时
tcp-keepalive 0 # 0为表示禁用长连接
loglevel notice # 日志级别，debug，verbose，notice，warning
logfile "" # 日志文件的名称，默认输出到stdout，如果开启了daemonize，会输出到/dev/null
databases 16 #支持的最大的数据库数
save 900 1 # RDB持久化策略900s内数据发生了1次更新的话就会触发RDB持久化
save 300 10 # 5分钟
save 60 10000 # 1分钟
stop-writes-on-bgsave-error yes # 发生异常时，redis不再支持写功能
rdbcompression yes # RDB持久化时，需要压缩
rdbchecksum yes # RDB数据恢复时，需要检验校验和，CRC64，校验和默认在放在文件结尾
dbfilename dump.rdb  #rdb持久化默认保存的文件名
dir ./ # RDB和AOF文件的目录
slave-serve-stale-data yes # slave实例在失去与master的连接时是否继续提供服务
slave-read-only yes # slave实例只读，建议设置成yes
repl-disable-tcp-nodelay no # 是否禁用nodelay，nodelay开启时，所有的数据都会即时发送，而不是积累一定的数据量然后打包发送
slave-priority 100 # 从实例优先级，如果为0表示不参与master竞选，大于0时，数字越小越可能被选中为master
appendonly no #是否启用aof，从实例建议关闭，
appendfilename "appendonly.aof" # aof模式下，生成的文件名称
appendfsync everysec # aof模式默认的持久化规则，1/次/秒
no-appendfsync-on-rewrite no # 在aof同步时，是否暂缓新数据的append写入
auto-aof-rewrite-percentage 100 #　当aof文件达到100%，也就是64mb时，进行重写
auto-aof-rewrite-min-size 64mb # aof文件的最小值
aof-load-truncated yes # 开启时，如果redis故障了，那么会加载aof文件，并且以日志方式通知用户
lua-time-limit 5000 #　lua脚本运行的最大时间，ms
slowlog-log-slower-than 10000 # 当语句执行时间大于10000微秒时，就是慢日志
slowlog-max-len 128 # 慢日志的最大条数，超过时，清除旧的慢日志
latency-monitor-threshold 0 # 用于设置监控哪些超过预订时间的操作，此处为0表示停用监控
notify-keyspace-events "" #通知keyspace的事件，为空表示关闭
hash-max-ziplist-entries 512 # ziplist中的最大条目数
hash-max-ziplist-value 64 # 每个条目最大字节数
list-max-ziplist-entries 512 # 同上
list-max-ziplist-value 64
set-max-intset-entries 512 # 同上
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000 # 小于此值的使用稀疏数据结构（sparse），大于的话使用稠密数据结构（dense）
activerehashing yes # 开启顶层数据结构的rehash功能，内存足够时可使用
client-output-buffer-limit normal 0 0 0 # hard soft seconds ，超过buffer就关闭连接，soft和second同时超过时也关闭连接
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10 # redis-server后台执行task的频率
aof-rewrite-incremental-fsync yes # 增量文件同步策略，开启时，每32mb就进行fsync写入磁盘，从而避免文件太大时对磁盘的操作过多

RDB持久化

RDB是redis默认的持久化方式
默认工作机制：定时将内存中的数据以快照的形式保存到文件dump.rdb中

# 获取dump.rdb所在的目录
~]$ redis-cli
127.0.0.1:6379> config get dir
1) "dir"
2) "/var/lib/redis/6379"  # 说明dump.rdb在/var/lib/redis/6379目录下
127.0.0.1:6379> bgsave
Background saving started # 数据量较少时，执行完就可以直接去dir目录中查看dump.rdb文件 

RDB触发机制

1.在指定时间内执行了指定次数的写操作

save 900 1 #900秒发生一次写操作就触发RDB持久化，以下同理
save 300 10
save 60 10000

2.手动执行save或bgsave命令

save命令会阻塞主线程，从而导致redis服务不可用，因此不建议使用
bgsave命令会使主线程fork出一个子线程，由子线程在后台执行RDB的持久化操作

RDB模式的优缺点
优点：

1.适合大规模的数据恢复
2.对业务数据完整性和一致性要求不是很高时，推荐使用RDB

缺点：

1.可能在进行持久化的时候宕机，那样的话数据就有丢失的风险
2.redis在备份时会占用内存，备份过程中先将内存中的数据写入到内存中的一个临时文件中，相当于占用了双倍内存，然后才会用临时文件来替换原来的文件
因此，RBD持久化模式下，应该将持久化的时间设定在半夜业务低峰时期

AOF持久化

AOF默认不开启，AOF是为了弥补RBD模式的数据不一致性，AOF机制采用的是记录每次数据操作，并追加到appendonly.aof文件中。恢复时，再根据日志文件从前至后执行文件中的每条指令
开启AOF

修改配置文件
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
修改完成后，最好再执行以下命令：
127.0.0.1:6379>config set appendonly yes
最后可以在/var/lib/redis/6379目录下找到appendonly.aof文件

配置AOF的重写机制

auto-aof-rewrite-percentage 100  # 当aof文件达到了上次重写的大小，并且超过了64mb，那么就开始重写
auto-aof-rewrite-min-size 64mb   #重写时aof文件的最小值，生产配置一般比64mb大很多，通常是几个G

正常情况下，redis即使宕机了，只要appendonly.aof文件还在，那么重启redis后就可以获取原来的数据，丢失的数据顶多就是宕机的那一秒内的数据
如果appendonly.aof文件格式发生错误，那么就可以使用以下方式修复

首先切换到redis的src目录
~]$ cd /usr/local/redis/src
~]$ redis-check-aof --fix /var/lib/redis/6379/appendonly.aof #appendonly文件的路径需要指定好
AOF analyzed: size=283, ok_up_to=283, diff=0 #返回的内容
AOF is valid

AOF重写原理
aof文件会随着数据修改操作的变多而变得很大，因此当达到了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size设定的值之后，就会触发重写操作
redis先fork出一个子线程，然后子线程将内存中的数据写入到临时文件，最后替换旧的aof文件

AOF持久化的优缺点
优点：

1.数据的一致性高
缺点：
1.如果有大量的数据操作，aof文件会变得很大，从而导致恢复数据时负载很高，恢复得也较慢