共计 2159 个字符，预计需要花费 6 分钟才能阅读完成。
开发环境原本一片祥和（外表上看起来），就在为上线做筹备，验证零碎某一个关键性问题的时候，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。