Redis学习-数据持久化

Redis学习-数据持久化

Redis是内存型数据库，在服务器产生突发情况，如断电，服务器崩溃等情况时，如果不及时将redis存储在内存中的数据持久化到硬盘中，则会产生数据丢失的问题。Redis为此问题提供了两种解决方案。快照与AOF。

1. 快照

快照（snapshotting），通常叫做RDB持久化，因为它持久化文件的名字后缀为.rdb，它可以为某一个时间点上redis存储在内存中的数据创建一个副本，并将该副本持久化到硬盘中。

创建快照相关的命令和配置：

1. BGSAVE: reids-cli通过向redis发送bgsave命令来创建一个快照，redis会fork一个子进程来将快照写入硬盘，父进程继续处理请求，也就是在创建快照的时间点之后父进程处理的请求不会被持久化到硬盘中。

   root@40ac31896fb2:/data# redis-cli
   127.0.0.1:6379> bgsave
   Background saving started
   

2. SAVE：redis-cli向redis发送save命令来创建一个快照，这时候redis不会创建子进程，而是停止响应，专心进行快照的创建和持久化。因为不会处理接下来的请求，也就不存在丢失快照时间点之后数据的问题。

   127.0.0.1:6379> save
   OK
   

   执行完bgsave或save命令后，在相应的目录下会产生rdb文件：

   root@40ac31896fb2:/data# ls
   dump.rdb
   

3. 相关配置项:

   ################################ SNAPSHOTTING  ################################
   # 配置文件中默认有三个配置，只要满足其中一个就创建快照
   # 解释：以第一个配置为例，在900s内，若有1次写入，即创建快照
   # 开启：只要有save配置，即开启rdb持久化
   # 关闭：在save配置的最后追加 save ""，即可关闭rdb持久化
   save 900 1
   save 300 10
   save 60 10000
   # save ""
   # 持久化出现错误是否继续进行，yes不继续
   stop-writes-on-bgsave-error yes
   # 是否压缩快照
   rdbcompression yes
   # 是否校验快照文件
   rdbchecksum yes
   # 快照文件名
   dbfilename dump.rdb
   # 快照存储位置
   dir ./
   

关于使用快照持久化的优缺点和使用场景我们在介绍完AOF后再总结

2. AOF

AOF持久化，即将redis-cli执行的命令不断追加到一个日志文件中，日志文件的名字后缀为.aof。在恢复数据的时候，直接将日志文件中的redis命令执行一遍就可以了

aof持久化相关配置与解释：

############################## APPEND ONLY MODE ###############################

# AOF持久化开关,yes开启
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# 文件追加策略：
# 1. always，只要有redis-cli执行一条命令，立即进行保存，持久化的数据最完整，但不建议使用，因为操作频繁时，严重影响性能,还会毁硬盘
# 2. everysec，每秒记录一次redis-cli执行过的命令，可能会丢失1s的数据
# 3. no, 持久化的时机交给系统，Linux系统通常为30s一次，将缓冲区的数据写到磁盘上，即可能丢失30的数据
appendfsync everysec

# 正在写入磁盘时，新的请求不写入，等当前写入完成后再写入，默认是no，比较安全
# 如果对实时性要求很高，可以改为yes，因为持久化频繁的进行IO操作，可能会造成延迟
# 总的来说建议使用no
no-appendfsync-on-rewrite no

# 当aof文件大小超过之前的百分比为100时，进行重写
auto-aof-rewrite-percentage 100
# 为了防止aof文件过小，依然进行重写，设置一个发生重写的最小值
auto-aof-rewrite-min-size 64mb

# redis启动时，自动加载aof文件来恢复数据
aof-load-truncated yes

aof听起来很好的样子，还要rdb干什么！

看下面的问题：

我们说了，aof持久化类似于日志记录，那么当执行的命令非常多时，aof的文件就可能变得非常大，很可能就变成rdb文件大小的数倍，在redis重启时，恢复数据也很慢。

解决方案：

我们发现配置中这么两项：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

这就是redis的重写策略。用户可以通过向redis发送BGREWRITEAOF命令，这个命令会移除aof文件中冗余的命令来重写aof文件，使aof文件变得尽可能小。

原理与创建快照相似：redis fork一个子进程对aof文件进行重写。

单纯进行重写的缺点：

1. 子进程进行重写时会降低性能
2. 若aof文件很大，删除原有aof文件，重写新文件严重降低性能

因此，通过上面的两个配置来控制重写，可以一定程度上改善这个问题。

不过在实际情况中依然会出现OOM（OutOfMemery）的问题，这里转载一篇不错的redis优化的文章：

优化 | Redis AOF重写导致的内存问题

3. 持久化策略选择

1. 如果redis数据库完全被用作缓存，果断关闭持久化策略
2. 数据量不大，且容忍一定程度的丢失，使用RDB
3. 实际在使用过程中通常会进行主从配置，读写分离，来增大吞吐量。
   1. master关闭持久化以提高处理请求的性能
   2. slave关RDB，开AOF，编写定时任务脚本，定时备份aof文件
   3. slave关rewrite，编写定时任务脚本，在空闲时间使用bgrewriteaof命令手动进行重写（因为rewrite会降低性能）

附录：

1.引用

1. 《redis实战》
2. redis持久化方式的选择
3. 优化 | Redis AOF重写导致的内存问题

2. 下载资料

1. 各个版本redis的下载地址：http://download.redis.io/releases/