redis持久化
Redis是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题，Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失，rdb与aof。
RDB持久化
redis提供了RDB持久化的功能，这个功能可以将redis在内存中的的状态保存到硬盘中，它可以手动执行。也可以再redis.conf中配置，定期执行。RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。
优点：速度快，适合做备份，主从复制就是基于RDB持久化功能实现
缺点：耗时，耗性能：不可控，可能会丢失数据
触发机制-主要三种方式
'''
save(同步)
1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件
2 会造成redis的阻塞（数据量非常大的时候）
3 文件策略：如果老的RDB存在，会替换老的
4 复杂度 o(n)
'''
'''
bgsave(异步，Backgroud saving started)
1 客户端执行bgsave命令----》redis服务端----》异步创建RDB二进制文件（fork函数生成一个子进程（fork会阻塞reids），执行createRDB，执行成功，返回给reids消息）
2 此时访问redis，会正常响应客户端
3 文件策略：跟save相同，如果老的RDB存在，会替换老的
4 复杂度 o(n)
'''
'''
自动（通过配置）
配置 seconds changes
save 900 1
save 300 10
save 60 10000
如果60s中改变了1w条数据，自动生成rdb
如果300s中改变了10条数据，自动生成rdb
如果900s中改变了1条数据，自动生成rdb
以上三条符合任意一条，就自动生成rdb，内部使用bgsave
'''
#配置：
save 900 1 #配置一条
save 300 10 #配置一条
save 60 10000 #配置一条
dbfilename dump.rdb #rdb文件的名字，默认为dump.rdb
dir ./ #rdb文件存在当前目录
stop-writes-on-bgsave-error yes #如果bgsave出现错误，是否停止写入，默认为yes
rdbcompression yes #采用压缩格式
rdbchecksum yes #是否对rdb文件进行校验和检验
#最佳配置
save 900 1
save 300 10
save 60 10000
dbfilename dump-${port}.rdb #以端口号作为文件名，可能一台机器上很多reids，不会乱
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes #出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验
触发机制-不容忽略的方式
1 全量复制 #没有执行save和bgsave没有添加rdb策略，还会生成rdb文件，如果开启主从复制，主会自动生成rdb
2 debug reload #debug级别的重启，不会将内存中的数据清空
3 shutdown save#关闭会出发rdb的生成
RDB实践
- 启动redis服务端,准备配置文件
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379 #定义持久化文件存储位置
dbfilename dbmp.rdb #rdb持久化文件
bind 10.0.0.10 127.0.0.1 #redis绑定地址
requirepass redhat #redis登录密码
save 900 1 #rdb机制 每900秒 有1个修改记录
save 300 10 #每300秒 10个修改记录
save 60 10000 #每60秒内 10000修改记录
-
启动redis服务端
-
登录redis设置一个key
redis-cli -a redhat
-
此时检查目录，/data/6379底下没有dbmp.rdb文件
-
通过save触发持久化，将数据写入RDB文件
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> save
OK
AOF
记录服务器执行的所有变更操作命令（例如set del等），并在服务器启动时，通过重新执行这些命令来还原数据集
AOF 文件中的命令全部以redis协议的格式保存，新命令追加到文件末尾。
优点：最大程序保证数据不丢
缺点：日志记录非常大
AOF的三种策略
AOF持久化配置，两条参数
appendonly yes
appendfsync always 总是修改类的操作
everysec 每秒做一次持久化
no 依赖于系统自带的缓存大小机制
日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上
always：redis--》写命令刷新的缓冲区---》每条命令fsync到硬盘---》AOF文件
everysec（默认值）：redis——》写命令刷新的缓冲区---》每秒把缓冲区fsync到硬盘--》AOF文件
no:redis——》写命令刷新的缓冲区---》操作系统决定，缓冲区fsync到硬盘--》AOF文件
| 命令 | always | everysec | no |
|---|---|---|---|
| 优点 | 不丢失数据 | 每秒一次fsync，丢失1秒数据 | 不用管 |
| 缺点 | IO开销大，一般的sata盘只有几百TPS | 丢1秒数据 | 不可控 |
案例
1.准备aof配置文件 redis.conf
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379
dbfilename dbmp.rdb
requirepass redhat
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
2.启动redis服务
redis-server /etc/redis.conf
3.检查redis数据目录/data/6379/是否产生了aof文件
[root@web02 6379]# ls
appendonly.aof dbmp.rdb redis.log
4.登录redis-cli，写入数据，实时检查aof文件信息
[root@web02 6379]# tail -f appendonly.aof
5.设置新key，检查aof信息，然后关闭redis，检查数据是否持久化
redis-cli -a redhat shutdown
redis-server /etc/redis.conf
redis-cli -a redhat
AOF 重写
随着命令的逐步写入，并发量的变大， AOF文件会越来越大，通过AOF重写来解决该问题
| 原生AOF | AOF重写 |
|---|---|
| set hello world set hello java set hello hehe incr counter incr counter rpush mylist a rpush mylist b rpush mylist c 过期数据 |
set hello hehe set counter 2 rpush mylist a b c |
本质就是把过期的，无用的，重复的，可以优化的命令，来优化
这样可以减少磁盘占用量，加速恢复速度
实现方式
bgrewriteaof：
客户端向服务端发送bgrewriteaof命令，服务端会起一个fork进程，完成AOF重写
AOF重写配置：
| 配置名 | 含义 |
|---|---|
| auto-aof-rewrite-min-size | AOF文件重写需要尺寸 |
| auto-aof-rewrite-percentage | AOF文件增长率 |
| 统计名 | 含义 |
|---|---|
| aof_current_size | AOF当前尺寸（单位：字节） |
| aof_base_size | AOF上次启动和重写的尺寸（单位：字节） |
自动触发时机（两个条件同时满足）：
aof_current_size>auto-aof-rewrite-min-size：当前尺寸大于重写需要尺寸
(aof_current_size-aof_base_size)/aof_base_size>auto-aof-rewrite-percentage:（增长率）当前尺寸减去上次重写的尺寸，除以上次重写的尺寸如果大于配置中的增长率
重写流程
配置
appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly-${port}.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
dir /bigdiskpath #存放的路径
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失
RDB和AOF的选择
rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog
rdb和aof的比较
| 命令 | rdb | aof |
|---|---|---|
| 启动优先级 | 低 | 高(挂掉重启，会加载aof的数据) |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 重 | 轻 |
rdb最佳策略
rdb关掉，主从操作时
集中管理：按天，按小时备份数据
主从配置，从节点打开
aof最佳策略
开：缓存和存储，大部分情况都打开，
aof重写集中管理
everysec：通过每秒刷新的策略
RDB持久化切换AOF持久化
注意：确保redis版本在2.2以上
[root@pyyuc /data 22:23:30]#redis-server -v
Redis server v=4.0.10 sha=00000000:0 malloc=jemalloc-4.0.3 bits=64 build=64cb6afcf41664c
本文在redis4.0中，通过config set命令，达到不重启redis服务，从RDB持久化切换为AOF
- redis.conf服务端配置文件
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379
dbfilename dbmp.rdb
save 900 1 #rdb机制 每900秒 有1个修改记录
save 300 10 #每300秒 10个修改记录
save 60 10000 #每60秒内 10000修改记录
- 启动redis服务端
redis-server redis.conf
- 登录redis-cli插入数据，手动持久化
127.0.0.1:6379> set name chaoge
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> set addr shahe
OK
127.0.0.1:6379> save
OK
- 检查RDB文件
[root@pyyuc /data 22:34:16]#ls 6379/
dbmp.rdb redis.log
- 备份这个rdb文件，保证数据安全
[root@pyyuc /data/6379 22:35:38]#cp dbmp.rdb /opt/
- 执行命令，开启AOF持久化
127.0.0.1:6379> CONFIG set appendonly yes #开启AOF功能
OK
127.0.0.1:6379> CONFIG SET save "" #关闭RDB功能
OK
- 确保数据库的key数量正确
127.0.0.1:6379> keys *
1) "addr"
2) "age"
3) "name"
- 确保插入新的key，AOF文件会记录
127.0.0.1:6379> set title golang
OK
此时RDB已经正确切换AOF，注意还得修改redis.conf添加AOF设置，不然重启后，通过config set的配置将丢失