Redis for OPS 03：数据安全与持久化

写在前面的话

通过前两节，除了安装部分，其它的更多的是作为了解，除非我们面向实际的开发，当然知道更多总是好的，这样才有吹牛逼的资本。

从本节开始我们主要谈谈作为一个运维，在处理 Redis 的维护的时候应该注意哪些方面。

数据持久化

在说持久化之前我们需要了解，Redis 之所以快，原因在于它的数据默认存储在内存中，内存的读写速度相较于 MySQL 这类关系型数据库从硬盘读取肯定是快了不知道多少倍。但同时也存在一个问题，服务器宕机，服务挂掉都会使得内存中的数据丢失，如果只是 Session 类的数据还好，但真正用起 Redis 的肯定不只是存 Session 这么简单，这里面肯定会包含一部分不那么重要，但是又不能缺少的数据。

那如何保证该部分数据在服务器宕机或者服务挂掉的时候尽可能的保证数据不丢失，归根结底，还是需要将数据刷写到磁盘。所以便有了数据的持久化。

Redis 为我们提供了两种数据持久化的方法：RDB 和 AOF

RDB：

能在指定的时间间隔将数据刷写到磁盘，生成快照。

优点在于快，适合当做备份，主从复制就是基于 RDB 实现。缺点在于很难保证数据的完整性，在宕机和持久化之间可能会缺失一点数据。

配置方法，在 redis.conf 中加入如下配置：

# 快照保存名字
dbfilename dump-6379.rdb

# 快照保存目录
dir "/data/services/redis/data"

# 持久化规则，15分钟一次变化，5分钟10次变化。1分钟10000次变化都会触发持久化
save 900 1
save 300 10
save 60 10000

# 如果开启RDB快照，如果持久化失败，Redis就会拒绝所有写请求
stop-writes-on-bgsave-error yes

# 对于快照是否进行压缩
rdbcompression yes

此时重启 Redis 然后可以手动持久化一次查看效果，否则只能等上面的规则触发持久化：

此时去 data 目录查看：

这就是快照，由于没啥数据，所以很小，所谓的备份，就是备份该文件。

AOF：

对于 Redis 的持久化，我们可以参照 MySQL 的数据备份来做参考，RDB 就像我们写的定时任务定期去 mysqldump，而 AOF 则更像 bin log，你所做的每一步都会保存到持久化文件中，能够最大程度的保存服务器在宕机的时候数据完整性。

当然也有问题，那就是因为所有操作都记录，会导致该文件特别大，不过我们可以使用命令来精简它。

在服务器同时开启 RDB 持久化和 AOF 持久化，在恢复的时候默认优先选择 AOF，因为数据完整度更高。

配置方法，在 redis.conf 中加入如下配置：

# RDB持久化宕机可能丢失部分数据，AOF相当于MySQL binlog
appendonly yes

# AOF持久化文件名称
appendfilename "appendonly-6379.aof"

# 持久化策略always/no/always
appendfsync everysec

# AOF重写或写入RDB时候会产生大量IO，此时AOF的fsync将阻塞很久，如果应用无法接受这种延迟则设置为yes，则rewrite期间不fsync
no-appendfsync-on-rewrite yes

# 自动重写，当前AOF超过上一次重写时百分之多少触发重写
auto-aof-rewrite-percentage 100

# 最小达到多大才重写，避免很小的时候就重写
auto-aof-rewrite-min-size 64mb

# AOF文件尾部可能不完整，redis启动时，数据载入。yes会自动修复，否则可能需要手动redis-check-aof
aof-load-truncated yes

# 4.0 开始允许两种持久化混合
aof-use-rdb-preamble no

重启 Redis 之后执行 save 此时再度查看 data 目录：

可以看到生成了 AOF 持久化文件！

扩展：AOF 文件可能会损坏，但是可以使用 Redis 的工具来修复它。

修复原则：在修复之前，我们需要先将文件备份，避免修复失败数据永久性丢失！

redis-check-aof --fix appendonly-6379.aof

安全配置

持久化算是 Redis 的一种安全策略，另外一种安全策略就是绑定 IP 和设置密码：

# 保护模式，如果【yes】必须绑定IP或者设置密码
protected-mode yes

# 绑定IP地址，多个使用空格隔开，全部可以使用0.0.0.0
bind 127.0.0.1 192.168.200.101

# 配置密码
requirepass helloworld

还有更复杂的安全策略，比如将一些关键的命令进行重命名，避免倍别人连接上去乱改。

当然我们一般不会这样做，对于数据库类的服务，在生产中我们一般选用不带有公网连接的配置，最大程度保持数据安全性。