今天开发突然和我说redis不能写了。我进入redis后发现确实是这样，不可以执行set指令了。报错如下：
172.31.18.90:6379> set test test1 (error) MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
之前redis一直是正常的。不是权限问题导致的，也不是内存耗尽通过查看log发现是这个报错fork: Cannot allocate memory
在小内存的进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。找到原因之后，直接修改内核参数 vm.overcommit_memory = 1,sysctl -p 使内核参数生效.
Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
如果 vm.overcommit_memory = 1，直接放行vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。vm.overcommit_memory = 2：则会比较 进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap，决定是否放行。
这里在重新发一下redis 的回写机制,Redis的数据回写机制分同步和异步两种，同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。
在redis中运行config set stop-writes-on-bgsave-error no命令只能暂时解决不能set的问题。出了问题还是要看log的默认配置 stop-writes-on-bgsave-error yes当bgsave出错时数据将不能修改。
