对比官方推荐两个都启用此时AOFRDB如果对数据不敏感可以选单独用RDB。不建议单独用 AOF因为可能会出现Bug。如果只是做纯内存缓存可以都不用。对比项RDBAOF本质二进制快照保存某一时刻的全量数据追加写命令日志记录所有写操作持久化方式定时/手动生成快照文件dump.rdb将写命令追加到 AOF 文件触发方式save、bgsave、配置规则、关闭时等由appendonly yes开启按appendfsync策略刷盘刷盘策略快照周期决定always每条命令都刷盘everysec每秒刷盘no由操作系统决定数据安全性较低可能丢失最后一次快照后的数据较高everysec最多丢约 1 秒always基本不丢性能影响bgsave会 fork 子进程数据量大时影响内存和 CPU写命令频繁追加always性能较差重写时也会 fork文件大小较小二进制压缩存储通常较大保存的是命令日志可重写压缩恢复速度快直接加载二进制快照慢需要重放命令文件越大越慢适合场景全量备份、灾备、快速恢复对数据丢失敏感、要求高可靠主要优点文件紧凑、恢复快、适合备份实时性好、丢失数据少、可读性较强主要缺点可能丢数据fork 有开销文件大、恢复慢、写放大默认情况Redis 默认开启 RDBAOF 默认关闭需要配置appendonly yes混合持久化Redis 4.0 支持 RDBAOF 混合持久化AOF 重写时前半部分为 RDB 格式后半部分为增量命令兼顾恢复速度和数据安全性一句话总结RDB 是“定时拍快照”文件小、恢复快但可能丢数据AOF 是“记写命令日志”数据更安全但文件大、恢复慢。生产上常结合使用或开启混合持久化。官网建议RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储AOF持久化方式记录每次对服务器写的操作当服务器重启的时候会重新执行这些命令来恢复原始的数据AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写使得AOF文件的体积不至于过大只做缓存如果你只希望你的数据在服务器运行的时候存在你也可以不使用任何持久化方式.当同时开启两种持久化方式在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢 建议不要因为RDB更适合用于备份数据库(AOF在不断变化不好备份) 快速重启而且不会有AOF可能潜在的bug留着作为一个万一的手段。性能建议因为RDB文件只用作后备用途建议只在Slave上持久化RDB文件而且只要15分钟备份一次就够了只保留save 900 1这条规则。如果使用AOF好处是在最恶劣情况下也只会丢失不超过两秒数据启动脚本较简单只load自己的AOF文件就可以了。代价,一是带来了持续的IO二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可应该尽量减少AOF rewrite的频率AOF重写的基础大小默认值64M太小了可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。RDB-二进制快照1、RDB机制每隔一段时间进行持久化操作。在指定的时间间隔内将内存中的数据集快照写入磁盘 也就是行话讲的Snapshot快照它恢复时是将快照文件直接读到内存里备份是如何执行的Redis会单独创建fork一个子进程来进行持久化会先将数据写入到 一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。 整个过程中主进程是不进行任何IO操作的这就确保了极高的性能 如果需要进行大规模数据的恢复且对于数据恢复的完整性不是非常敏感那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。Fork1.Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等 数值都和原进程一致但是是一个全新的进程并作为原进程的子进程2.在Linux程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会exec系统调用出于效率考虑Linux中引入了“写时复制技术”3.一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。RDB持久化流程2、RDB启动与配置dump.rdb文件在redis.conf中配置文件名称默认为dump.rdb配置位置rdb文件的保存路径也可以修改。默认为Redis启动时命令行所在的目录下dir “/myredis/”如何触发RDB快照保持策略配置文件中默认的快照配置命令save VS bgsavesave save时只管保存其它不管全部阻塞。手动保存。不建议。bgsaveRedis会在后台异步进行快照操作 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间flushall命令执行flushall命令也会产生dump.rdb文件但里面是空的无意义###SNAPSHOTTING快照###Save格式save 秒钟 写操作次数RDB是整个内存的压缩过的SnapshotRDB的数据结构可以配置复合的快照触发条件默认是1分钟内改了1万次或5分钟内改了10次或15分钟内改了1次。禁用不设置save指令或者给save传入空字符串stop-writes-on-bgsave-error当Redis无法写入磁盘的话直接关掉Redis的写操作。推荐yes.rdbcompression 压缩文件对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能。推荐yes.rdbchecksum 检查完整性在存储快照后还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗如果希望获取到最大的性能提升可以关闭此功能推荐yes.如何停止:动态停止RDBredis-cli config set save “”#save后给空值表示禁用保存策略3、RDB恢复# 1. 查询 RDB 工作目录redis-cli CONFIG GETdir# 输出示例dir /var/lib/redis# 2. 备份 RDB 文件cp/var/lib/redis/dump.rdb /backup/dump.rdb.$(date%Y%m%d%H%M%S)# 3. 关闭 Redissudosystemctl stop redis# 4. 把备份文件拷回工作目录并改名为 dump.rdbcp/backup/dump2.rdb /var/lib/redis/dump.rdb# 注意文件权限通常属主为 redis 用户sudochownredis:redis /var/lib/redis/dump.rdb# 5. 启动 Redis自动加载 RDBsudosystemctl start redis# 6. 验证redis-cli DBSIZE redis-cli GETyour:key4、优缺点优势1.适合大规模的数据恢复2.对数据完整性和一致性要求不高更适合使用3.节省磁盘空间4.恢复速度快劣势1.Fork的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑2.虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。3.在备份周期在一定间隔时间做一次备份所以如果Redis意外down掉的话就会丢失最后一次快照后的所有修改。AOF-记录写操作AOFAppend Only File记录操作命令1、机制以日志的形式来记录每个写操作增量保存将Redis执行过的所有写指令记录下来(读操作不记录) 只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作AOF默认不开启可以在redis.conf中配置文件名称默认为 appendonly.aofAOF文件的保存路径同RDB的路径一致。AOF重写Rewrite压缩机制是什么AOF采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制, 当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof重写原理如何实现重写AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)redis4.0版本后的重写是指上就是把rdb 的快照以二级制的形式附在新的aof头部作为已有的历史数据替换掉原来的流水账操作。no-appendfsync-on-rewrite如果 no-appendfsync-on-rewriteyes ,不写入aof文件只写入缓存用户请求不会阻塞但是在这段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能如果 no-appendfsync-on-rewriteno, 还是会把数据往磁盘里刷但是遇到重写操作可能会发生阻塞。数据安全但是性能降低触发机制何时重写Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写虽然可以节约大量磁盘空间减少恢复时间。但是每次重写还是有一定的负担的因此设定Redis要满足一定条件才会进行重写。auto-aof-rewrite-percentage设置重写的基准值文件达到100%时开始重写文件是原来重写后文件的2倍时触发auto-aof-rewrite-min-size设置重写的基准值最小文件64MB。达到这个值开始重写。例如文件达到70MB开始重写降到50MB下次什么时候开始重写100MB系统载入时或者上次重写完毕时Redis会记录此时AOF大小设为base_size,如果Redis的AOF当前大小 base_size base_size*100% (默认)且当前大小64mb(默认)的情况下Redis会对AOF进行重写。重写流程1bgrewriteaof触发重写判断是否当前有bgsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行。2主进程fork出子进程执行重写操作保证主进程不会阻塞。3子进程遍历redis内存中数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。41).子进程写完新的AOF文件后向主进程发信号父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。5使用新的AOF文件覆盖旧的AOF文件完成AOF重写。2、持久化流程1客户端的请求写命令会被append追加到AOF缓冲区内2AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中3AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF文件容量4Redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的3、启动与配置#找到并编辑 redis.confsudovim/etc/redis/redis.conf#开启 AOF 持久化appendonlyyes#可选指定 AOF 文件名默认即为 appendonly.aofappendfilenameappendonly.aof#同步策略# 每次写入都同步最安全性能最差appendfsync always# 每秒同步一次推荐常用appendfsync everysec# 不主动同步交给操作系统appendfsync no#重启 Redis 使配置生效sudosystemctl restart redis#或sudoserviceredis restart4、恢复AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样都是拷贝备份文件需要恢复时再拷贝到Redis工作目录下启动系统即加载。#正常恢复AOF 文件完好1、修改默认的appendonly no改为yes2、将有数据的aof文件复制一份保存到对应目录(查看目录config getdir)3、恢复重启redis然后重新加载#异常恢复AOF 文件损坏1、修改默认的appendonly no改为yes2、如遇到AOF文件损坏通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复3、备份被写坏的AOF文件4、恢复重启redis然后重新加载5、优缺点优势备份机制更稳健丢失数据概率更低。可读的日志文本通过操作AOF稳健可以处理误操作。劣势比起RDB占用更多的磁盘空间。恢复备份速度要慢。每次读写都同步的话有一定的性能压力。存在个别Bug造成恢复不能。
对比官方推荐两个都启用此时AOFRDB如果对数据不敏感可以选单独用RDB。不建议单独用 AOF因为可能会出现Bug。如果只是做纯内存缓存可以都不用。对比项RDBAOF本质二进制快照保存某一时刻的全量数据追加写命令日志记录所有写操作持久化方式定时/手动生成快照文件dump.rdb将写命令追加到 AOF 文件触发方式save、bgsave、配置规则、关闭时等由appendonly yes开启按appendfsync策略刷盘刷盘策略快照周期决定always每条命令都刷盘everysec每秒刷盘no由操作系统决定数据安全性较低可能丢失最后一次快照后的数据较高everysec最多丢约 1 秒always基本不丢性能影响bgsave会 fork 子进程数据量大时影响内存和 CPU写命令频繁追加always性能较差重写时也会 fork文件大小较小二进制压缩存储通常较大保存的是命令日志可重写压缩恢复速度快直接加载二进制快照慢需要重放命令文件越大越慢适合场景全量备份、灾备、快速恢复对数据丢失敏感、要求高可靠主要优点文件紧凑、恢复快、适合备份实时性好、丢失数据少、可读性较强主要缺点可能丢数据fork 有开销文件大、恢复慢、写放大默认情况Redis 默认开启 RDBAOF 默认关闭需要配置appendonly yes混合持久化Redis 4.0 支持 RDBAOF 混合持久化AOF 重写时前半部分为 RDB 格式后半部分为增量命令兼顾恢复速度和数据安全性一句话总结RDB 是“定时拍快照”文件小、恢复快但可能丢数据AOF 是“记写命令日志”数据更安全但文件大、恢复慢。生产上常结合使用或开启混合持久化。官网建议RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储AOF持久化方式记录每次对服务器写的操作当服务器重启的时候会重新执行这些命令来恢复原始的数据AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写使得AOF文件的体积不至于过大只做缓存如果你只希望你的数据在服务器运行的时候存在你也可以不使用任何持久化方式.当同时开启两种持久化方式在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢 建议不要因为RDB更适合用于备份数据库(AOF在不断变化不好备份) 快速重启而且不会有AOF可能潜在的bug留着作为一个万一的手段。性能建议因为RDB文件只用作后备用途建议只在Slave上持久化RDB文件而且只要15分钟备份一次就够了只保留save 900 1这条规则。如果使用AOF好处是在最恶劣情况下也只会丢失不超过两秒数据启动脚本较简单只load自己的AOF文件就可以了。代价,一是带来了持续的IO二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可应该尽量减少AOF rewrite的频率AOF重写的基础大小默认值64M太小了可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。RDB-二进制快照1、RDB机制每隔一段时间进行持久化操作。在指定的时间间隔内将内存中的数据集快照写入磁盘 也就是行话讲的Snapshot快照它恢复时是将快照文件直接读到内存里备份是如何执行的Redis会单独创建fork一个子进程来进行持久化会先将数据写入到 一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。 整个过程中主进程是不进行任何IO操作的这就确保了极高的性能 如果需要进行大规模数据的恢复且对于数据恢复的完整性不是非常敏感那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。Fork1.Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等 数值都和原进程一致但是是一个全新的进程并作为原进程的子进程2.在Linux程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会exec系统调用出于效率考虑Linux中引入了“写时复制技术”3.一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。RDB持久化流程2、RDB启动与配置dump.rdb文件在redis.conf中配置文件名称默认为dump.rdb配置位置rdb文件的保存路径也可以修改。默认为Redis启动时命令行所在的目录下dir “/myredis/”如何触发RDB快照保持策略配置文件中默认的快照配置命令save VS bgsavesave save时只管保存其它不管全部阻塞。手动保存。不建议。bgsaveRedis会在后台异步进行快照操作 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间flushall命令执行flushall命令也会产生dump.rdb文件但里面是空的无意义###SNAPSHOTTING快照###Save格式save 秒钟 写操作次数RDB是整个内存的压缩过的SnapshotRDB的数据结构可以配置复合的快照触发条件默认是1分钟内改了1万次或5分钟内改了10次或15分钟内改了1次。禁用不设置save指令或者给save传入空字符串stop-writes-on-bgsave-error当Redis无法写入磁盘的话直接关掉Redis的写操作。推荐yes.rdbcompression 压缩文件对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能。推荐yes.rdbchecksum 检查完整性在存储快照后还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗如果希望获取到最大的性能提升可以关闭此功能推荐yes.如何停止:动态停止RDBredis-cli config set save “”#save后给空值表示禁用保存策略3、RDB恢复# 1. 查询 RDB 工作目录redis-cli CONFIG GETdir# 输出示例dir /var/lib/redis# 2. 备份 RDB 文件cp/var/lib/redis/dump.rdb /backup/dump.rdb.$(date%Y%m%d%H%M%S)# 3. 关闭 Redissudosystemctl stop redis# 4. 把备份文件拷回工作目录并改名为 dump.rdbcp/backup/dump2.rdb /var/lib/redis/dump.rdb# 注意文件权限通常属主为 redis 用户sudochownredis:redis /var/lib/redis/dump.rdb# 5. 启动 Redis自动加载 RDBsudosystemctl start redis# 6. 验证redis-cli DBSIZE redis-cli GETyour:key4、优缺点优势1.适合大规模的数据恢复2.对数据完整性和一致性要求不高更适合使用3.节省磁盘空间4.恢复速度快劣势1.Fork的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑2.虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。3.在备份周期在一定间隔时间做一次备份所以如果Redis意外down掉的话就会丢失最后一次快照后的所有修改。AOF-记录写操作AOFAppend Only File记录操作命令1、机制以日志的形式来记录每个写操作增量保存将Redis执行过的所有写指令记录下来(读操作不记录) 只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作AOF默认不开启可以在redis.conf中配置文件名称默认为 appendonly.aofAOF文件的保存路径同RDB的路径一致。AOF重写Rewrite压缩机制是什么AOF采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制, 当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof重写原理如何实现重写AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)redis4.0版本后的重写是指上就是把rdb 的快照以二级制的形式附在新的aof头部作为已有的历史数据替换掉原来的流水账操作。no-appendfsync-on-rewrite如果 no-appendfsync-on-rewriteyes ,不写入aof文件只写入缓存用户请求不会阻塞但是在这段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能如果 no-appendfsync-on-rewriteno, 还是会把数据往磁盘里刷但是遇到重写操作可能会发生阻塞。数据安全但是性能降低触发机制何时重写Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写虽然可以节约大量磁盘空间减少恢复时间。但是每次重写还是有一定的负担的因此设定Redis要满足一定条件才会进行重写。auto-aof-rewrite-percentage设置重写的基准值文件达到100%时开始重写文件是原来重写后文件的2倍时触发auto-aof-rewrite-min-size设置重写的基准值最小文件64MB。达到这个值开始重写。例如文件达到70MB开始重写降到50MB下次什么时候开始重写100MB系统载入时或者上次重写完毕时Redis会记录此时AOF大小设为base_size,如果Redis的AOF当前大小 base_size base_size*100% (默认)且当前大小64mb(默认)的情况下Redis会对AOF进行重写。重写流程1bgrewriteaof触发重写判断是否当前有bgsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行。2主进程fork出子进程执行重写操作保证主进程不会阻塞。3子进程遍历redis内存中数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。41).子进程写完新的AOF文件后向主进程发信号父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。5使用新的AOF文件覆盖旧的AOF文件完成AOF重写。2、持久化流程1客户端的请求写命令会被append追加到AOF缓冲区内2AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中3AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF文件容量4Redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的3、启动与配置#找到并编辑 redis.confsudovim/etc/redis/redis.conf#开启 AOF 持久化appendonlyyes#可选指定 AOF 文件名默认即为 appendonly.aofappendfilenameappendonly.aof#同步策略# 每次写入都同步最安全性能最差appendfsync always# 每秒同步一次推荐常用appendfsync everysec# 不主动同步交给操作系统appendfsync no#重启 Redis 使配置生效sudosystemctl restart redis#或sudoserviceredis restart4、恢复AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样都是拷贝备份文件需要恢复时再拷贝到Redis工作目录下启动系统即加载。#正常恢复AOF 文件完好1、修改默认的appendonly no改为yes2、将有数据的aof文件复制一份保存到对应目录(查看目录config getdir)3、恢复重启redis然后重新加载#异常恢复AOF 文件损坏1、修改默认的appendonly no改为yes2、如遇到AOF文件损坏通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复3、备份被写坏的AOF文件4、恢复重启redis然后重新加载5、优缺点优势备份机制更稳健丢失数据概率更低。可读的日志文本通过操作AOF稳健可以处理误操作。劣势比起RDB占用更多的磁盘空间。恢复备份速度要慢。每次读写都同步的话有一定的性能压力。存在个别Bug造成恢复不能。
