Redis持久化

Redis 的持久化 - WK_BlogYard - 博客园 (cnblogs.com)

‍

我们知道，Redis数据库中的数据都是存放在内存中，虽然很高效，但是这样存在一个非常严重的问题，如果突然停电，那我们的数据不就全部丢失了吗？它不像硬盘上的数据，断电依然能够保存。

这个时候我们就需要持久化，我们需要将我们的数据备份到硬盘上，防止断电或是机器故障导致的数据丢失。

持久化的实现方式有两种方案：一种是直接保存当前已经存储的数据，相当于复制内存中的数据到硬盘上，需要恢复数据时直接读取即可；还有一种就是保存我们存放数据的所有过程，需要恢复数据时，只需要将整个过程完整地重演一遍就能保证与之前数据库中的内容一致。

RDB

RDB就是我们所说的第一种解决方案，那么如何将数据保存到本地呢？我们可以使用命令：

save
-- 注意上面这个命令是直接保存，会占用一定的时间，也可以单独开一个子进程后台执行保存
bgsave

执行后，会在服务端目录下生成一个dump.rdb文件，而这个文件中就保存了内存中存放的数据，当服务器重启后，会自动加载里面的内容到对应数据库中。保存后我们可以关闭服务器：

shutdown

重启后可以看到数据依然存在。

虽然这种方式非常方便，但是由于会完整复制所有的数据，如果数据库中的数据量比较大，那么复制一次可能就需要花费大量的时间，所以我们可以每隔一段时间自动进行保存；还有就是，如果我们基本上都是在进行读操作，而没有进行写操作，实际上只需要偶尔保存一次即可，因为数据几乎没有怎么变化，可能两次保存的都是一样的数据。

我们可以在配置文件中设置自动保存，并设定在一段时间内写入多少数据时，执行一次保存操作：

save 300 10 # 300秒（5分钟）内有10个写入
save 60 10000 # 60秒（1分钟）内有10000个写入

配置的save使用的都是bgsave后台执行。

AOF

虽然RDB能够很好地解决数据持久化问题，但是它的缺点也很明显：每次都需要去完整地保存整个数据库中的数据，同时后台保存过程中也会产生额外的内存开销，最严重的是它并不是实时保存的，如果在自动保存触发之前服务器崩溃，那么依然会导致少量数据的丢失。

而AOF就是另一种方式，它会以日志的形式将我们每次执行的命令都进行保存，服务器重启时会将所有命令依次执行，通过这种重演的方式将数据恢复，这样就能很好解决实时性存储问题。

但是，我们多久写一次日志呢？我们可以自己配置保存策略，有三种策略：

• always：每次执行写操作都会保存一次
• everysec：每秒保存一次（默认配置），这样就算丢失数据也只会丢一秒以内的数据
• no：看系统心情保存

可以在配置文件中配置：

# 注意得改成也是
appendonly yes

# appendfsync always
appendfsync everysec
# appendfsync no

重启服务器后，可以看到服务器目录下多了一个appendonly.aof​文件，存储的就是我们执行的命令。

AOF的缺点也很明显，每次服务器启动都需要进行过程重演，相比RDB更加耗费时间，并且随着我们的操作变多，不断累计，可能到最后我们的aof文件会变得无比巨大，我们需要一个改进方案来优化这些问题。

Redis有一个AOF重写机制进行优化，比如我们执行了这样的语句：

lpush test 666
lpush test 777
lpush test 888

实际上用一条语句也可以实现：

lpush test 666 777 888

正是如此，只要我们能够保证最终的重演结果和原有语句的结果一致，无论语句如何修改都可以，所以我们可以通过这种方式将多条语句进行压缩。

我们可以输入命令来手动执行重写操作：

bgrewriteaof

或是在配置文件中配置自动重写：

# 百分比计算，这里不多介绍
auto-aof-rewrite-percentage 100
# 当达到这个大小时，触发自动重写
auto-aof-rewrite-min-size 64mb

至此，我们就完成了两种持久化方案的介绍，最后我们再来进行一下总结：

• AOF：

  • 优点：存储速度快、消耗资源少、支持实时存储
  • 缺点：加载速度慢、数据体积大

• RDB：

  • 优点：加载速度快、数据体积小
  • 缺点：存储速度慢大量消耗资源、会发生数据丢失

‍

‍