标签：激活 数据恢复 文件 top 处理 ocs 资料 做了 nta
Redis作为一款内存数据库，自然所有数据都加载在内存中，那么自然就有小伙伴会问，如果服务器宕机了怎么办，数据不都丢了吗，不用担心，Redis早就提供了两种方式来将数据进行持久化，即便服务器宕机，在Redis重启后，数据也能恢复过来。这两种方式分别是RDB持久化和AOF持久化，那么这两种方式各有什么优劣、该如何配置、怎么去选择呢？请看下文：
RDB持久化实际上将Redis中的数据做了一份快照到本地文件中、定期备份，备份流程如下：
从上面的流程我们可以看出，RDB备份的效率比较高，如果发生宕机恢复的速度也很快。但是如果服务器发生宕机，没来得及写入磁盘的数据则会丢失；同时，在fork时，如果数据集比较大，也可能会阻塞一段时间Redis，所以对于数据安全性要求较高的可以考虑后面一种方式aof。相关配置：
################################ 快照 #################################
# 保存数据库到磁盘
# save 秒 更新次数
# 当秒和更新次数同时满足时，则执行RDB导出操作
save 900 1 # 过900秒后数据库发生了至少1个Key值改变则进行RDB操作
save 300 10 # 过300秒后数据库发生了至少10个Key值改变则进行RDB操作
save 60 10000 # 过60秒后数据库发生了至少10000个Key值改变则进行RDB操作
# 在默认情况下，当RDB操作被激活且持久化失败时，Redis是否停止接受更新操作
# 因为需要用户了解到数据并没有正确持久化，如果没人注意这个问题，将是一个灾难
# 当然如果你已经合理配置了Redis服务器的监视和备份，可以关掉此功能
stop-writes-on-bgsave-error yes
# 是否使用LZF压缩，使用了LZF压缩后的数据文件会比较小
# 如果你想节省一部分子进程的cpu消耗可以关闭此功能，但是会产生比较大的数据文件
rdbcompression yes
# 为了防止文件损坏，此选项可以追加一个循环冗余校验码（CRC64）到快照文件的末尾
# 但是他会消耗约10%的cpu，如果对性能追求极致，可以设置为no
rdbchecksum yes
# 导出的rdb文件名称
dbfilename dump.rdb
# 导出的rdb文件存储目录
dir ./AOF会以日志的形式记录服务器所处理的每个写、删除操作到文本中，具体步骤如下：
从操作步骤上来看，aof的方式无疑更为安全，但由于每一步操作都需要记录下来，效率相对低下，且会产生非常巨大的数据文件，恢复起来也很慢，相关配置如下：
# 是否打开aof日志功能
appendonly no
# aof文件存放路径与文件名称
appendfilename appendonly.aof
# always：每一个命令都同步到aof文件中去
# everysec：每秒写一次数据到aof文件中去
# no：交由操作系统判定缓存区大小，统一写入aof
# 相比之下always最安全，但是由于每次都要写入，开销大，速度慢；no的速度最快，但是同步频率比较低，容易丢失数据
#appendfsync always/everysec/no
# 在RDB操作时，是否停止aof操作，停止时，系统会等待rdb完成后，一次性将这期间的命令写入到aof中去
no-appendfsync-on-rewrite no
# 配置是否重写aof命令，该命令与auto-aof-rewrite-min-size配合使用，由于我们每次操作都会记录到aof文件中，那么aof文件就会变得非常庞大
# 例如我们对一个key进行了1000次set操作，最后他的结果是10，那么aof就会记录1000次，如果能根据数据库将这些操作合并为set key 10就好了
# 使用这个命令可以保证当aof增长是原来的100%时，则发生重写，这样就会大幅缩小aof文件的大小，也会提升aof的数据恢复效率
auto-aof-rewrite-percentage 100
# 当aof文件大于64mb时重写
auto-aof-rewrite-min-size 64mb 到这里想必大家也对于持久化有了基本的认识了，顺便推荐一本《Redis 设计与实现》翻资料的时候发现的，很适合入坑。
标签：激活 数据恢复 文件 top 处理 ocs 资料 做了 nta
原文地址：https://www.cnblogs.com/krockey/p/9361573.html
