工作問題之：redis 保存快照問題

今天開發(fā)突然和我說redis 不能寫了。我進(jìn)入redis后發(fā)現(xiàn)確實(shí)是這樣，不可以執(zhí)行set指令了。報(bào)錯(cuò)如下：

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一直是正常的。不是權(quán)限問題導(dǎo)致的，也不是內(nèi)存耗盡

通過查看log發(fā)現(xiàn)是這個(gè)報(bào)錯(cuò)fork: Cannot allocate memory

在小內(nèi)存的進(jìn)程上做一個(gè)fork,不需要太多資源，但當(dāng)這個(gè)進(jìn)程的內(nèi)存空間以Ｇ為單位時(shí)，fork就成為一件很恐怖的操作。何況在16G內(nèi)存的主機(jī)上fork 14G內(nèi)存的進(jìn)程呢？肯定會(huì)報(bào)內(nèi)存無法分配的。更可氣的是，越是改動(dòng)頻繁的主機(jī)上fork也越頻繁，fork操作本身的代價(jià)恐怕也不會(huì)比假死好多少。

找到原因之后，直接修改內(nèi)核參數(shù) vm.overcommit_memory = 1

sysctl -p 使內(nèi)核參數(shù)生效

參數(shù)解釋：

Linux內(nèi)核會(huì)根據(jù)參數(shù)vm.overcommit_memory參數(shù)的設(shè)置決定是否放行。

如果 vm.overcommit_memory = 1，直接放行

vm.overcommit_memory = 0：則比較 此次請(qǐng)求分配的虛擬內(nèi)存大小和系統(tǒng)當(dāng)前空閑的物理內(nèi)存加上swap，決定是否放行。

vm.overcommit_memory = 2：則會(huì)比較 進(jìn)程所有已分配的虛擬內(nèi)存加上此次請(qǐng)求分配的虛擬內(nèi)存和系統(tǒng)當(dāng)前的空閑物理內(nèi)存加上swap，決定是否放行。

這里在重新發(fā)一下redis 的回寫機(jī)制

Redis的數(shù)據(jù)回寫機(jī)制分同步和異步兩種，

同步回寫即SAVE命令，主進(jìn)程直接向磁盤回寫數(shù)據(jù)。在數(shù)據(jù)大的情況下會(huì)導(dǎo)致系統(tǒng)假死很長時(shí)間，所以一般不是推薦的。

異步回寫即BGSAVE命令，主進(jìn)程fork后，復(fù)制自身并通過這個(gè)新的進(jìn)程回寫磁盤，回寫結(jié)束后新進(jìn)程自行關(guān)閉。由于這樣做不需要主進(jìn)程阻塞，系統(tǒng)不會(huì)假死，一般默認(rèn)會(huì)采用這個(gè)方法。

這里注意：

在redis中運(yùn)行config set stop-writes-on-bgsave-error no命令只能暫時(shí)解決不能set的問題。出了問題還是要看log的

默認(rèn)配置 stop-writes-on-bgsave-error yes當(dāng)bgsave出錯(cuò)時(shí)數(shù)據(jù)將不能修改