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

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

此错误是由于BGSAVE失败导致的。在BGSAVE期间，Redis会fork一个子进程来将数据保存到磁盘上。虽然BGSAVE失败的确切原因可以从日志中检查(通常在linux机器上的/var/log/redis/redis-server.log)，但很多时候bgive失败是因为fork不能分配内存。很多时候，由于操作系统的优化冲突，fork无法分配内存(尽管机器有足够的可用RAM)。

可以从Redis常见问题中阅读:

Redis background saving schema relies on the copy-on-write semantic of fork in modern operating systems: Redis forks (creates a child process) that is an exact copy of the parent. The child process dumps the DB on disk and finally exits. In theory the child should use as much memory as the parent being a copy, but actually thanks to the copy-on-write semantic implemented by most modern operating systems the parent and child process will share the common memory pages. A page will be duplicated only when it changes in the child or in the parent. Since in theory all the pages may change while the child process is saving, Linux can't tell in advance how much memory the child will take, so if the overcommit_memory setting is set to zero fork will fail unless there is as much free RAM as required to really duplicate all the parent memory pages, with the result that if you have a Redis dataset of 3 GB and just 2 GB of free memory it will fail. Setting overcommit_memory to 1 says Linux to relax and perform the fork in a more optimistic allocation fashion, and this is indeed what you want for Redis.

Redis不需要像操作系统认为的那样多的内存来写入磁盘，所以可能会预先导致fork失败。

要解决这个问题，您可以:

修改/etc/sysctl.conf，增加:

vm.overcommit_memory=1

然后重新启动sysctl:

在FreeBSD上:

sudo /etc/rc.d/sysctl reload

在Linux上:

sudo sysctl -p /etc/sysctl.conf

在Redis有写权限的目录下启动Redis服务器

上面的答案肯定能解决你的问题，但实际情况是这样的:

存储rdb的默认位置。转储文件为。/(表示当前目录)。您可以在redis.conf文件中验证这一点。因此，启动redis服务器的目录就是转储文件所在的目录。RDB文件将被创建和更新。

似乎您已经开始运行redis服务器在一个目录，其中redis没有正确的权限来创建转储。rdb文件。

更糟糕的是，redis可能也不允许你关闭服务器，直到它能够创建rdb文件，以确保正确保存数据。

要解决这个问题，你必须使用redis-cli进入活动的redis客户端环境，更新dir键，并将其值设置为你的项目文件夹或任何非root用户有权限保存的文件夹。然后运行BGSAVE调用转储的创建。rdb文件。

CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE

(现在，如果您需要保存转储。RDB文件在您启动服务器的目录中，然后您需要更改该目录的权限，以便redis可以写入它。您可以搜索stackoverflow如何做到这一点)。

你现在应该可以关闭redis服务器了。注意，我们对路径进行了硬编码。硬编码很少是一个好的实践，我强烈建议从你的项目目录启动redis服务器，并将dir键更改回。/ '。

CONFIG SET dir "./"
BGSAVE

这样，当您需要redis为另一个项目时，转储文件将创建在当前项目的目录中，而不是在硬编码路径的项目目录中。

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

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

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

FWIW，我遇到了这个问题，解决方案是简单地向盒子添加一个交换文件。我使用了这个方法:https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04