我也遇到过类似的问题，这背后的主要原因是redis的内存消耗。 我的EC2机器有8GB内存(大约7.4 gb可用)

当我的程序运行时，RAM使用率上升到7.2 GB，只剩下大约100MB的RAM，这通常会触发MISCONF Redis错误…

可以使用htop命令确定内存消耗。执行htop命令后，查找Mem属性。如果它显示出较高的消耗(比如我的情况是7.2GB/7.4GB)，那么最好将实例升级为更大的内存。 在这种情况下，使用set stop-writes-on-bgsave-error no对服务器来说将是一场灾难，并可能导致中断服务器上运行的其他服务(如果有的话)。所以，最好避免配置命令和升级你的REDIS机器。

供您参考:您可能需要安装htop才能使其工作:sudo apt-get install htop

另一种解决方案是在你的系统上运行一些其他的内存大的服务，检查在你的服务器/机器/实例上运行的其他服务，如果没有必要就停止它。要检查机器上运行的所有服务，请使用service——status-all

对于那些直接粘贴config命令的人，建议在使用这些命令之前，请做一些研究，至少警告用户。正如@Rodrigo在评论中提到的:“忽视错误看起来并不酷。”

——更新

你也可以配置maxmemory和maxmemory-policy来定义当达到特定的内存限制时Redis的行为。 例如，如果我想保持6GB的内存限制，并从DB中删除最近最少使用的键，以确保redis mem的使用不超过6GB，那么我们可以设置以下两个参数(在redis.conf或CONFIG set命令中):

maxmemory 6gb
maxmemory-policy allkeys-lru

你可以为这两个参数设置很多其他的值，你可以从这里阅读:https://redis.io/topics/lru-cache

使用redis-cli，你可以阻止它尝试保存快照:

config set stop-writes-on-bgsave-error no

这是一个快速的解决方法，但是如果你关心使用它的数据，你应该检查一下为什么bgsave首先失败了。

在我的例子中，原因是磁盘的可用空间非常低(只有35 Mb)。我做了以下的事情

停止所有Redis相关进程 删除磁盘中的一些文件，以腾出足够的空间 删除redis转储文件(如果不需要现有数据) Sudo rm /var/lib/redis/* 删除所有现有数据库的所有键 Sudo redis-cli flushall 重新启动所有芹菜任务，并检查相应的日志是否有任何问题

现在，Redis的写访问问题在官方的Redis docker容器中重新出现，给客户端这个错误消息。

来自官方Redis映像的Redis试图将.rdb文件写入containers /data文件夹中，这是相当不幸的，因为它是一个根目录拥有的文件夹，而且它也是一个非持久化的位置(如果容器/pod崩溃，写入那里的数据将消失)。

所以在一个小时的不活动后，如果你以非根用户运行你的redis容器(例如docker run -u 1007而不是默认的docker run -u 0)，你会在你的服务器日志中得到一个非常详细的错误信息(参见docker logs redis):

1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error

所以你需要做的是将容器的/data文件夹映射到一个外部位置(非根用户，这里:1007，有写权限，比如主机上的/tmp)，例如:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

所以这是官方docker镜像的错误配置(应该写入/tmp而不是/data)，产生了这个“定时炸弹”，你很可能只会在生产中遇到…在某个特别安静的假日周末过夜:/

感谢大家检查这个问题，显然错误是在bgsave期间产生的。

对我来说，在shell中输入config set stop-writes-on-bgsave-error no并重新启动Redis解决了这个问题。

是的，这是因为当前用户没有修改“dump.rdb”的权限。

因此，除了创建一个新的RDB文件，您还可以对旧文件授予权限(更改其所有权)。

在redis-cli中输入:

配置get dir

你会得到"/usr/local/var/db/redis"(这是redis写入数据的位置)

使用终端前往此位置

cd 
cd /usr/local/var/db

输入以下命令(使用我们的用户名):

sudo chown -R [username] db

这将改变为所有者。

这对我很有用。