redis持久化

一、RDB（redis数据快照）

    含义：Redis数据快照，也就是把内存中的所有数据整体记录到磁盘中，如果redis实例故障重启，可以从磁盘中读取快照文件，恢复数据

实操命令

redis-cli #连接redis
save #Redis主进程执行rdb，会阻塞所有命令
bgsave # 开启子进程执行rdb，避免主进程受到影响

    redis.conf文件下也有对应的设置

# 900s内，如果至少有1个key被修改，则执行bgsave
save 900 1
save 300 10
save 60 10000

执行原理

执行bgsave命令的时候会把主进程fork得到子进程，子进程和主进程共享同一片物理内存，这时子进程就可以读取内存文件存到rdb中了

    这种方式存在脏读的问题，所以fork采用的是copy-on-write技术，也就是让数据加上read-only的锁

    当主进程执行读操作时，访问共享内存

    当主进程执行写操作时，只能先拷贝一份数据，执行写操作

二、AOF（追加文件）

    含义：可以称为追加文件，redis所处理的每一个写命令都会记录到AOF中，可以看作是命令文件

    aof默认是关闭的，需要修改redis.conf配置来开启

# 是否开启AOF功能，默认是no
appendonly yes
# aof文件的名称
appendfilename "appendonly.aof"
# aof命令记录的频率
appendfsync no/always/everysec

配置项	刷盘时机	优点	缺点
always	同步刷盘（每执行一次写命令，立即记录到AOF文件中）	可靠性高，几乎不丢数据	性能较差
everysec	每秒刷盘（每隔1s将缓冲区数据写到AOF文件中）	性能中	最多丢失1s数据
no	操作系统控制（由操作系统决定何时将缓冲区内容写回磁盘）	性能最好	可靠性差，可能丢失大量数据

    因为AOF是记录命令，所以要比记录数据的RDB大得多，因为AOF会记录对同一个key多次写操作，但只有最后一次才有意义，那么为了减少aof体积，我们可以合并命令，通过bgrewriteaof命令，可以让aof文件执行重写命令，用最少的命令达到相同的效果

    redis.conf配置aof触发阈值重写aof

# 文件比上次超多百分之百，也就是上次aop文件两倍触发重写
auto-aof-rewrite-percentage 100
# aop文件体积最小达到多大触发重写
auto-aof-rewrite-min-size 64mb

三、RDB和AOF对比

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次写命令
数据完整性	不完整，两次备份之间会有数据丢失	相对完整，取决于刷盘策略
文件大小	有压缩，体积小	记录文件，体积大
宕机恢复速度	很快	慢（因为体积）
数据恢复优先级	低，因为数据相对不完整	高
系统占用资源	高，大量的cpu和内存	低，记录命令的时候只使用IO资源 但是aof重写的时候会占用大量的cpu和内存
使用场景	可以接受数分钟数据丢失，追求更快的启动速度	对数据的安全性要求高

视频地址：5.redis持久化_哔哩哔哩_bilibili

系统笔记：java面经 | 雪儿Snowy (snowyee.cn)