重庆网站搜索排名,游戏程序开发,免费网络app,营销型网站建设风格设定Redis提供了两种持久化数据的方式。一种是RDB快照#xff0c;另一种是AOF日志。RDB快照是一次全量备份#xff0c;AOF日志是连续的增量备份。RDB快照是以二进制的方式存放Redis中的数据#xff0c;在存储上比较紧凑#xff1b;AOF日志记录的是对内存数据修改的指令文本记录…Redis提供了两种持久化数据的方式。一种是RDB快照另一种是AOF日志。RDB快照是一次全量备份AOF日志是连续的增量备份。RDB快照是以二进制的方式存放Redis中的数据在存储上比较紧凑AOF日志记录的是对内存数据修改的指令文本记录。Redis提供的持久化机制可以有效的避免Redis因为进程退出导出的数据丢失问题。
1、RDB快照持久化
RDB持久化是在某个时间点做一次全量的数据备份。触发RDB持久化的方式分为手动触发和自动触发。
1.1、手动触发
手动触发分别对应save和bgsave命令
save命令会阻塞当前Redis服务器直到RDB过程完成为止如果数据量较大的话会造成长时间的阻塞线上环境不建议使用。bgsave命令就是background save。执行bgsave命令时Redis主进程会fork一个子进程来进行数据的备份完成后自动结束(操作系统的copy on write机制简称COW)。所以Redis主进程阻塞时间只在fork阶段那一会。相对于save命令阻塞时间更短。
1.2、自动触发
配置redis.conf触发规则自动执行
# 当在规定的时间内Redis发生了写操作的个数满足条件会触发发生BGSAVE命令。
# save seconds changes
# 当用户设置了多个save的选项配置只要其中任一条满足Redis都会触发一次BGSAVE操作
save 900 1
save 300 10
save 60 10000
# 以上配置的含义900秒之内至少一次写操作、300秒之内至少发生10次写操作、
# 60秒之内发生至少10000次写操作只要满足任一条件均会触发bgsave执行shutdown命令关闭服务器时如果没有开启AOF持久化功能那么会自动执行一次bgsave命令。如果从节点执行全量复制操作主节点会自动执行bgsave命令生成RDB文件并发送给从节点。更多细节见主从同步。执行debug reload命令重新加载Redis时也会自动触发save操作。
1.3、RDB执行流程
Redis使用操作系统的多进程(Copy On Write, COW)机制来实现RDB快照持久化。
执行bgsave命令时Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务如果有的话直接返回。Redis主进程会fork一个子进程来执行RDB的持久化操作fork操作会阻塞主进程(影响Redis的读写)fork操作完成之后会发消息给主进程从而不再阻塞主进程。(阻塞主进程只在fork子进程时后续的子进程处理操作都不会阻塞主进程)通过 info stats 命令可以查看latest_fork_usec选项可以获取最近一个fork操作的耗时单位为微秒。主进程fork完子进程后bgsave命令会返回“BackGround saving started”信息并不再阻塞主进程可以继续响应其他命令。子进程创建RDB文件根据主进程生成临时快照文件持久化完成后会使用临时快照文件替换掉原来的RDB文件(该过程不会影响主进程的读写但Redis的写操作不会同步到主进程的内存中而是会写到一个临时的内存区域作为一个副本)。执行lastsave命令可以获取最后一次生成的RDB时间对应info统计的rdb_last_save_time选项。子进程完成RDB持久化后会发消息给主进程通知RDB持久化完成(同时将上阶段内存副本中的增量写数据同步到主内存中)。 1.4、RDB优缺点
1.4.1、优点
RDB文件小(二进制存储比较紧凑)非常适合定时备份用于灾难恢复。Redis加载RDB文件的速度比AOF快很多因为RDB文件中直接存储的是内存数据而AOF文件中存储的是一条条命令需要重新执行一遍。
1.4.2、缺点
RDB无法做到实时持久化若在两次bgsave命令间宕机则会丢失两次执行区间内的增量数据不适合用于实时性要求较高的场景。RDB的cow机制中fork子进程属于重量级操作并且会阻塞主进程RDB文件使用特定的二进制格式保存Redis版本演化过程中有多个格式的RDB版本存在老版本Redis服务无法兼容新版RDB文件格式的问题。
2、AOF日志持久化
AOF(append only file)持久化以独立日志的方式记录每次的写命令重启时需要重新执行一遍AOF文件中的命令来达到恢复数据的目的。AOF日志会在持续运行中逐渐增大由于Redis重启过程需要优先加载AOF日志进行指令重放以恢复数据恢复时间会无比漫长。所以需要定期进行AOF重写对AOF日志进行瘦身(合并命令)目前AOF是Redis的主流持久化方式。
2.1、开启方式
AOF默认是关闭的通过redis.conf配置文件进行开启。
## 此选项为aof功能的开关默认为“no”可以通过“yes”来开启aof功能
## 只有在“yes”下aof重写/文件同步等特性才会生效
appendonly yes ## 指定aof文件名称
appendfilename appendonly.aof ## 指定aof操作中文件同步策略有三个合法值always everysec no,默认为everysec
appendfsync everysec
## 在aof-rewrite期间appendfsync是否暂缓文件同步no表示“不暂缓”“yes”表示“暂缓”默认为“no”
no-appendfsync-on-rewrite no ## aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite默认“64mb”建议“512mb”
auto-aof-rewrite-min-size 64mb ## 相对于“上一次”rewrite本次rewrite触发时aof文件应该增长的百分比
## 每一次rewrite之后redis都会记录下此时“新aof”文件的大小(例如A)
## aof文件增长到A*(1 p)之后触发下一次rewrite每一次aof记录的添加都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100AOF是对文件的操作因此对于变更比较频繁的服务那么会造成磁盘的IO负荷加重。此外因为Linux对文件的操作是采用‘延迟写入’的方式因此并非每次对文件的write操作都会立即写入到磁盘中而是进入到一个buffer中当buffer中的数据达到阈值时就会触发实际写入(也有其他时机)这是Linux对文件系统的优化。 同时Linux也提供fsync(int fd)函数可以用来将指定文件的内容强制刷新到磁盘中。只要Redis进程实时调用fsync函数就可以保证AOF日志的内容不会丢失。但是fsync是个磁盘IO操作他很慢如果Redis执行一条指令就要执行fsync一次那么Redis的性能就会收到很大的影响。 因此Redis在其配置文件中提供了3中策略用来同步AOF日志记录
always每一条AOF指令都立即同步到磁盘文件中性能很低但是很安全。everysec每秒同步一次性能和安全都比较中庸也是Redis推荐的方式。如果遇到服务器宕机的情况最多会丢失1s的AOF日志记录。noRedis永不直接调用fsync文件同步而是将文件同步操作交给系统来决定何时同步磁盘。性能较好但是不安全。
2.2、重写(rewrite)机制
随着Redis运行时间的增长AOF日志文件会越来越大为了解决这个问题Redis需要定期对AOF日志进行重写来对AOF日志文件进行瘦身。 AOF Rewrite虽然是‘压缩’AOF文件的过程但是并非是采用‘基于原AOF文件’进行重写或者压缩操作的。而是类似RDB快照的方式基于Copy On Write全量遍历内存中的数据然后逐个序列化到文件汇总。因此AOF rewrite能够正确反映当前内存数据的状态。 AOF重写(bgrewriteaof)和ADB(bgsave)过程类似都是fork一个子进程来进行处理。 AOF对日志文件进行压缩时为了防止单条命令过大造成客户端缓冲区溢出对于list、set、zset、hash等类型操作以64个元素为界进行拆分成多条。 AOF重写降低了文件的大小另一方面更小的文件可以更快的被Redis加载。
在重写过程中对于新的变更操作将仍然被写入到原AOF文件中同时这些新的变更操作也会被Redis收集起来(aof-rewrite-buffer)。当内存中的数据全被写入到新的AOF文件后收集的新的变更操作也会一并追加到新AOF文件中。然后将新的AOF文件命名为appendonly.aof使用新的AOF文件替换掉老的AOF文件。
2.3、触发机制
和RDB类似AOF也有两种触发机制**手动触发和自动触发**。
2.3.1、手动触发
直接调用bgrewriteaof命令。 redis-cli -h ip -p port bgrewriteaof 2.3.2、自动触发
根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机 auto-aof-rewrite-min-size表示运行AOF文件重写时的文件最小体积默认为64MB。 auto-aof-rewrite-percentage代表当前AOF文件空间(auto_current_size)和上一次重写后AOF文件空间(aof_base_size)的值 自动触发时机auto_current_sizeauto_aof_rewrite_min_size (auto_current_size-auto_base_size)/auto_base_size auto_aof_rewrite_percentage 其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。
当Redis重启时可以加载AOF文件进行数据恢复。
2.4、AOF优缺点
2.4.1、优点
AOF只是追加写入文件对服务器性能影响较小速度比RDB要快消耗的内存较少。
2.4.2、缺点
AOF方式生成的日志文件会越来越大因此需要不断的进行AOF重写进行瘦身。即使经过AOF重写由于文件是文本文件文件提交较大(相比较于二进制文件)。AOF重写命令式的恢复数据速度明显比RDB慢。
3、Redis 4.0混合式持久化
仅使用RDB快照方式恢复数据由于快照时间粒度较大会丢失大量的数据。仅使用AOF重放方式恢复数据日志性能相对于RDB来说慢。且需要不停的进行日志的重写。在Redis实例很大的情况下启动需要花费很长的时间。
Redis 4.0为了解决这个问题带来一个全新的持久化选项–**混合持久化。**将RDB的内容和增量的AOF日志文件放在一起。这里的AOF日志不再是全量的日志而是自持久化开始到持久化结束的这段时间发生的增量AOF日志通常这部分AOF日志很小。相当于
大量数据使用粗粒度(时间上)的rdb快照方式性能高回复时间快。增量数据使用细粒度(时间上)的AOF日志尽量保证数据不丢失。
在Redis重启时可以先加载RDB文件然后在重放AOF日志就可以完全替代之前的AOF全量文件重放重启效率因此大幅度提升。
