在采取任何行动之前检查你的Redis日志。这个线程中的一些解决方案可能会删除你的Redis数据，所以要小心你在做什么。

在我的例子中，机器的内存快用完了。当主机上没有更多的空闲磁盘空间时，也会发生这种情况。

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

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

在我的情况下，这只是特权，我需要允许Redis接受传入的请求。

所以我重启了Redis服务通过Homebrew brew服务停止Redis和brew服务启动Redis和运行Redis服务器本地Redis -server。命令提示符要求我允许传入请求，然后它开始工作。

如果您在Linux机器上工作，还要重新检查数据库的文件和文件夹权限。

数据库和它的路径可以通过以下方式获得:

在redis-cli:

CONFIG GET dir 配置dbfilename

在命令行中ls -l。目录的权限应为755，文件的权限应为644。此外，通常redis-server作为用户redis执行，因此通过执行sudo chown -R redis:redis /path/to/rdb/folder，给用户redis文件夹的所有权也是很好的。在这里的回答中已经详细说明了这一点。

遇到此错误，并且能够从日志中找出该错误是由于磁盘空间不足造成的。所有插入到我箱子里的数据都不再需要了。所以我试着冲洗马桶。由于redis-rdb-bgsave进程正在运行，因此也不允许FLUSH数据。我按照下面的步骤，并能够继续。

登录redis客户端 执行config set stop-writes-on-bgsave-error no 执行FLUSHALL(不需要存储的数据) 执行config set stop-writes-on-bgsave-error yes

进程redis-rdb-bgsave在执行以上步骤后不再运行。

现在，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)，产生了这个“定时炸弹”，你很可能只会在生产中遇到…在某个特别安静的假日周末过夜:/