Redis的持久化

RDB手动触发更新，bgsave

基础了解

RDB持久化存储
- RDB介绍
- RDB优缺点：快照方式；数据恢复；实时性；二进制格式；数据压缩
- RDB触发方式：
- 手动触发：bgsave
- 自动触发：根据主配置文件中的save关键字
- RDB文件存储位置及存储名称：
- 通过配置中定义：服务启动的时候可以进行指定dir & dbfilename
- 服务启动时，热更新配置：
config set dir /path/to/
config set dbfilename value
- redis服务时，会去 dir 下读取 dbfilename 文件；如果有dbfilename文件则进行数据恢复

- RDB工作流程： .... 
- 停止RDB持久化：通过配置文件中注释 save 关键字

配置实验

服务器
[[e-mail] ~]# cd /var/lib/redis/
[[e-mail] redis]# ls
dump.rdb
[[e-mail] redis]# systemctl stop redis
[[e-mail] redis]# systemctl restart redis


客户端
[[e-mail] ~]# redis-cli 
127.0.0.1:6379> set k1 100
OK
127.0.0.1:6379> set key 200
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> keys *
1) "key"
2) "k1"
127.0.0.1:6379> set k3 300
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit
[[e-mail] ~]# redis-cli
127.0.0.1:6379> keys *
1) "key"
2) "k1"

RDB工作流程

1、客户端执行bgsave命令，发送给主进程
2、redis父进程就收到besave的命令，fork()创建一个子进程，
3、当子进程完成后，接着响应客户端的其他命令
4、子进程负责将内存中的数据打上快照生成RDB文件，存储在本地指定文件
127.0.0.1:6379> config get dir
1) “dir”
2) “/var/lib/redis”
或者通过配置文件的dir查看
5、子进程完成工作后发送信号通知父进程

AOF手动触发更新

基础概念

AOF持久化存储
- AOF介绍
- AOF优缺点：实时性对比；文件体积；数据恢复；兼容性
- AOF触发方式：
- 手动触发： bgrewriteaof操作
- 自动触发：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• AOF文件存储位置及存储名称：
  - 打开AOF持久化存储1: appendonly no & appendfilename “appendonly.aof”
  - 服务启动时，热更新配置：
  127.0.0.1:6379> config set appendonly yes

- AOF工作流程：...

  
    指定同步策略：  appendfsync everysec
         
    
- AOF重写工作流程：1. 如何做到实时持久化存储的 2. 为什么需要进行重写操作

- 持久化存储的选择：大数据量，小并发量；小数据量，大并发量 如何选择持久化存储？


- AOF和RDB文件同时存在的时候：redis服务如何去选择，优先加载AOF文件 

实验配置

打开AOF模式，并看日志信息

客户端

127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"



127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379> set key1 100
OK
127.0.0.1:6379> set key2 200
OK
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

服务端
[[e-mail] redis]# ls
appendonly.aof  dump.rdb


[[e-mail] ~]# tail /var/log/redis/redis.log 
7940:M 02 Apr 17:31:43.705 * The server is now ready to accept connections on port 6379
7940:M 02 Apr 17:53:48.909 * Background append only file rewriting started by pid 7994
7940:M 02 Apr 17:53:48.951 * AOF rewrite child asks to stop sending diffs.
7994:C 02 Apr 17:53:48.951 * Parent agreed to stop sending diffs. Finalizing AOF...
7994:C 02 Apr 17:53:48.952 * Concatenating 0.00 MB of AOF diff received from parent.
7994:C 02 Apr 17:53:48.952 * SYNC append only file rewrite performed
7994:C 02 Apr 17:53:48.952 * AOF rewrite: 4 MB of memory used by copy-on-write
7940:M 02 Apr 17:53:48.979 * Background AOF rewrite terminated with success
7940:M 02 Apr 17:53:48.979 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)


7940:M 02 Apr 17:56:28.382 * Background saving terminated with success
7940:M 02 Apr 17:56:42.568 * Background append only file rewriting started by pid 7999
7940:M 02 Apr 17:56:42.610 * AOF rewrite child asks to stop sending diffs.
7999:C 02 Apr 17:56:42.610 * Parent agreed to stop sending diffs. Finalizing AOF...
7999:C 02 Apr 17:56:42.611 * Concatenating 0.00 MB of AOF diff received from parent.
7999:C 02 Apr 17:56:42.611 * SYNC append only file rewrite performed
7999:C 02 Apr 17:56:42.611 * AOF rewrite: 4 MB of memory used by copy-on-write
7940:M 02 Apr 17:56:42.625 * Background AOF rewrite terminated with success
7940:M 02 Apr 17:56:42.625 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
7940:M 02 Apr 17:56:42.626 * Background AOF rewrite finished successfully

关闭redis，验证持久化

服务端
[[e-mail] redis]# ls
appendonly.aof  dump.rdb
[[e-mail] redis]# rm dump.rdb 
rm：是否删除普通文件 "dump.rdb"？y
[[e-mail] redis]# ls
appendonly.aof
[[e-mail] redis]# systemctl stop redis
[[e-mail] redis]# systemctl restart redis




客户端
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

127.0.0.1:6379> keys *
1) "k1"
2) "key1"
3) "key2"
4) "key"
127.0.0.1:6379> keys *
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> keys *
1) "key"
2) "key2"
3) "k1"
4) "key1"

工作流程

1、用户操作命令追加到AOF buf中
2、AOF缓冲区会将操作命令根据指定同步策略写到AOF文件中
3、进行重写操作（新的AOF替换旧的AOF文件）
4、服务启动时，可以去加载aof文件，达到数据恢复效果

同步策略

AOF默认
127.0.0.1:6379> config get appendfsync
1) “appendfsync”
2) “everysec”

同步策略
AOF同步策略：调用两个系统接口：write & fsync

write操作： 会触发延迟写机制，因为Linux在内核提供页缓冲区来提供磁盘IO性能；write操作在写入系统缓冲区后直接返回，同步硬盘依赖于系统调度机制

fsync操作： 针对单个文件操作，做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化

always： 保证文件存储到磁盘中才返回（write -> 缓冲区 -> fsync操作 -> 磁盘上） （可靠性更好，阻塞更长）

no： 只能保证文件存储到缓冲区中（write -> 缓冲区后便返回； 缓冲区中的数据同步到磁盘上是由 系统调度机制去完成的） 堵塞相对较短，但是可靠性不高

everysec：调用write操作将内存中的数据写入到缓冲区中，然后后台会有一个专门的fsync线程每s执行一次将缓冲区的内容写入到磁盘中

相对于 always 和 no 来说：可靠性和效率都有所保证；默认同步策略

重写流程

左侧正常操作，右侧rewrite追加上
1、执行bgrewriteaof操作交给redis父进程
2、父进程fork()创建一个子进程(完成AOF生成替换工作)
3、父进程继续响应用户请求操作，写两份
a)再接收的命令写入aof_buf中，追加到原本的aof文件中
b)根据当前客户端操作命令接着写入aof_rewrite_buf
4、子进程根据内存数据集完成追加AOF文件的工作
5、还需要将aof_rewrite_buf中的数据追加到aof文件中(从而保证子进程创建aof文件时，父进程继续响应用户请求数据丢失问题，实时性提高)
6、新的AOF文件替换旧的AOF文件
为什么需要重写？
a:set k1 100
b: del k1
AOF ： set k1 100 del k1 //完全没必要写