Redis的持久化

开发环境本来一片祥和（表面上看起来），就在为上线做准备，验证系统某一个关键性问题的时候，Redis集群突然不能用了，并给出了下面这段非常“友好”的提示。

Caused by: redis.clients.jedis.exceptions.JedisDataException: 
    MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk.
    Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). 
    Please check the Redis logs for details about the RDB error.

虽然第一次见到这个问题，但是这里出现的RDB，只能联想到Redis的持久化。

于是，从持久化开始找问题。
首先是确保生成的rdb文件没有问题，在服务器上执行命令检查rdb的合法性
redis-check-rdb dump.rdb

顺带将aof也检测一下
redis-check-aof appendonly.aof

如果aof文件存在问题，还可以通过命令修复（这里的修复是将有问题的部分删除）
redis-check-aof --fix appendonly.aof

我啰嗦一下redis的持久化机制，Redis是折腾内存的，但内存有个问题，一旦断电，所有的数据都会丢失。所以就需要有一个机制来处理这种可能出现的情况。于是Redis出现了两种持久化策略，分别是RDB和AOF。

---

RDB

RDB就是指Redis DataBase，是Redis中默认开启的持久化策略，在配置文件中处于SNAPSHOTTING模块。

规则

当满足某一种规则时，Redis就会fork一个子进程（一说Redis单线程），将数据写入到一个临时文件，当这个临时文件写完之后，再将原来的dump.rdb文件替换为这个临时文件，这就完成了一次持久化操作。Redis配置文件中默认提供了三种规则：

• 900秒内（15分钟）至少有一个key变更
• 300秒内（5分钟）至少有十个key变更
• 60秒内至少有一万个key变更
  每一种规则被满足都会触发持久化，我们就可以根据自己的情况修改这个配置或增减配置。
  当然，还有另外两种情况也会生成rdb文件，一种是关闭redis的时候，还有一种是执行save或者bgsave命令的时候；虽然flushall命令也会生成rdb文件，但这条命令是清空数据库，会得到一个空的rdb文件。

恢复RDB

将rdb文件放到dir指定的目录下，并确保rdb开启，启动redis即可。

关闭RDB

将所有规则注释后，配置 save ' ' 。

其他配置

• stop-writes-on-bgsave-error: 当持久化出现问题时，停止写入redis，默认yes
• rdbcompression: 对rdb文件做压缩，默认yes
• rdbchecksum: 对生成的rdb文件做校验，默认yes
• dbfilename: 保存的rdb文件名称，默认dump.rdb
• dir: 保存rdb文件的路径；恢复rdb数据时将rdb文件放在此目录下

优缺点

RDB文件紧凑，占用空间小；写入rdb时不会占用主进程；适合大量数据的备份与恢复；
RDB只能备份到某个时间节点，并且可能会丢失最后一次备份后的更改数据；此外，fork子进程时，需要一块与主进程相同大小的内存空间；

---

AOF

AOF是指 append only file，是一种记录执行命令的方式，将执行命令追加到文件末尾，redis配置种默认关闭。处于配置种的 APPEND ONLY MODE模块。

开启

配置文件中修改appendonly值为yes

规则

AOF也有自己的规则：

• appendfsync always：每一条命令都会做持久化，性能消耗大
• appendfsync everysec：每一秒做一次持久化，可能会丢失一秒内的数据
• appendfsync no：持久化时机交由操作系统控制，安全性低

恢复RDB

将aof文件放到dir指定的目录下，并确保rdb开启，启动redis即可。

其他配置

• appendfilename：生成aof文件名称，默认appendonly.aof
• no-apendfsync-on-rewrite: 这个配置就是我查到的解决问题的配置，默认为no，搜到的资料都让我改成yes。不明白为什么要这么改，所以没有修改。
• auto-aof-rewrite-min-size: 为了避免aof文件过于臃肿，允许aof文件达到某一大小后触发重写，重写会将aof做整合，降低磁盘占用。该配置需要满足下面的百分比。
• auto-aof-rewrite-percentage: aof重写百分比配置，默认100%。当aof文件达到上一个文件的某个百分比时，触发重写，该配置需满足上面的重写最小尺寸。

---

结束

在处理问题的时候，还找到了一个很奇怪的现象，cpu为什么这么高？

接下来不知道怎么处理，又想到之前看过的文章Redis和es被利用挖矿，索性不深究，直接kill。