Redis学习笔记(一)-持久化
一、RDB持久方式
RDB持久化是把当前进程的数据已快照的形式保存到硬盘的过程。
触发方式：
1、手动触发命令：save和bgsave
save：阻塞式，内存较大的实例在执行过程中会造成长时间的阻塞，影响主进程上的正常服务请求。
bgsave：fork子进程，RDB持久化的过程在子进程中进行，完成后自动结束进程，并通知主进程。阻塞发生在fork阶段，时间较短。
2、自动触发：满足RDB持久化条件后会自动执行持久化过程。
- 相关配置：
################# SNAPSHOTTING ####################
# 触发自动保存条件 # save <seconds> <changes>
# save <秒> <修改次数>
# 900s有一次改变触发一次持久化
save 900 1
save 300 10
save 60 10000
# 设置保存快照失败时，是否停止redis命令写入
# 默认开启，拒绝所有写操作，保证内存和持久化数据一致
stop-writes-on-bgsave-error yes
# 是否在导出.rdb文件时采用LZC压缩
rdbcompression yes
#是都开启CRC64校验
rdbchecksum yes
# 保存数据库的文件名称
dbfilename dump.rdb
# 保存数据库的文件所在目录 dir ./
########################################
- 从节点执行全量复制操作。
- 执行debug reload命令。
- shutdown命令，若未开启aof自定执行bgsave
持久化失败的可能原因：fork子进程内存不足，或rdb所在文件夹没有写权限。
优缺点：
优点：
- 保存了某个时间点的数据，适合备份；
- 与AOF相比，恢复大数据集效率更高；
缺点：
- 非实时备份，redis宕机时会丢失部分数据；
- 数据大时，fork子进程比较耗时，会阻塞客户端响应；
- RDB文件需满足特定格式，兼容性差；
二、AOF持久化方式
AOF持久化是通过保存redis服务器执行的写命令来记录数据库状态。即当redis执行了写命令，该命令就会被追加到AOF文件末尾。
开启AOF持久化：
1 ############################## APPEND ONLY MODE ###############################
# 开启aof,默认关闭 appendonly yes
# 保持的文件名
appendfilename "appendonly.aof"
# 同步策略
# always 每次有新命令，就将缓冲区写入同步到AOF文件
# everysec(默认) 每秒写入并同步
# no 同步操作交给操作系统
appendfsync everysec
# 重写时是否继续写AOF文件（开启IO性能会影响redis性能）
no-appendfsync-on-rewrite no
# 是否忽略最后一条可能存在问题的命令（宕机会导致数据不完整）
aof-load-truncated yes
#################################################################################
执行流程：
1、命令追加到AOF缓冲区（减少硬盘IO开销）;
2、缓冲区根据不同策略将数据同步到硬盘;
3、定期重写AOF文件，达到压缩目的；
AOF重写：
触发方式：
1、手动触发：执行bgrewriteaof命令。
2、自动触发：当配置的条件同时满足时，自动执行AOF重写。
# AOF文件当前大小/上次重写时大小，默认比值100，即当前大小是基准大小的2倍
auto-aof-rewrite-percentage 100
# AOF文件的最小体积，默认64MB
auto-aof-rewrite-min-size 64mb
执行流程：
- 主进程fork子进程执行rewrite，开销等同bgsave;
- fork子进程完成后，主进程继续响应其他命令，此时在保证原有AOF机制正确执行外，额外将新命令追加到一个重写缓冲区内(子进程只共享fork时的内存数据，新追加的数据临时保存在重写缓冲区)
- 子进程根据内存快照重写命令道新的AOF文件。
- 子进程重写结束后发送信号给主进程，主进程接收到信号更新统计信息，并将重写缓冲区内命令追加到新的AOF文件；
- 替换旧的AOF文件；
优缺点
优点：
- 支持秒级数据持久化;
- AOF文件可读性高，易于分析；
- 兼容性高，可用于不同版本redis；
缺点：
- 文件大，恢复速度慢。
- 对文件写数据频率较高，IO压力大
