redis开启aof持久化有什么影响

转载

字节小舞神 2024-09-06 19:30:54

文章标签 redis开启aof持久化有什么影响 redis redis持久化 RDB持久化 AOF持久化 文章分类 Redis 数据库

redis持久化

redis支持RDB和AOF两种持久化机制，持久化可以避免因进程退出而造成数据丢失;

一、RDB

1.1. 什么是RDB持久化

RDB持久化就是把当前进程数据生成快照(.rdb)二进制文件保存到硬盘的过程，持久化的触发方式分为手动触发和自动触发

1.2. RDB自动触发持久化原理

redis会单独fork一个当前进程一模一样的子进程来进行持久化，这个子进程的所有数据(变量、环境变量、程序计数器等)都和原进程一模一样，会先将数据写入到一个临时文件中，等待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何IO操作，同时能够响应客户端的请求

1.3. RDB手动触发持久化原理

redis手动触发有save和bgsave两种命令

1.3.1. save

阻塞当前redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

1.3.2. bgsave

redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短(微秒级)，是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave

1.4. RDB持久化的优点/缺点

优点

1、压缩后的二进制文件，相同数据量的.rdb文件要比.aof文件要小，适用于备份、全量复制，用于灾难恢复

2、加载RDB恢复数据远快于AOF方式

3、能够避免在服务进程进行IO操作

缺点

1、无法做到实时持久化，当缓存中的数据在系统宕机之前还未持久化时，还没来得及写入磁盘的数据都将丢失

2、每次都要创建子进程，频繁操作成本过高；如果数据集过大，在fork子进程的时候可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟

3、保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

1.5. redis.conf RDB持久化配置详解

save 900 1
#在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照
save 300 10
#在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照
save 60 10000
#在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照

二、AOF

2.1. 什么是AOF持久化

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决，AOF持久化生成.aof文件。AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录

开启：redis.conf设置：appendonly yes (默认不开启，为 no)

2.2. AOF运行流程

1，所有的写入命令(set hset)会append追加到aof_buf缓冲区中

2，AOF 缓冲区向硬盘做sync同步

3，随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩

4，当redis服务重启，可load加载AOF文件进行恢复AOF 持久化流程:命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)

redis开启aof持久化有什么影响_RDB持久化

2.3. AOF的优点/缺点

优点

1、该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失；而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中，这种方式在效率上是最低的；不同步的话全依赖操作系统自身的同步，redis的同步没有保证，性能最好

2、由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3、如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建

缺点

1、对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度比AOF的恢复速度要快。

2、根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了

2.4. redis.conf AOF持久化配置详解

# 启用AOF持久化方式
appendonly yes

# 每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
# appendfsync always
# 每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
appendfsync everysec
# 完全依赖 os，性能最好,持久化没保证(操作系统自身的同步)
# appendfsync no

# 正在导出rdb快照的过程中,要不要停止同步aof
no-appendfsync-on-rewrite yes

# 100%时,重写
# AOF文件大小比起上次重写时的大小,增长率
auto-aof-rewrite-percentage 100

# AOF文件,至少超过64M时,重写
auto-aof-rewrite-min-size 64mb