Redis设置值失败，真是让人头大又崩溃的惨痛经历

根据知乎问题“Redis设置值失败，真是让人头大又崩溃的惨痛经历”下的真实用户回答整理，引用部分将直接标注为“知乎用户A”、“知乎用户B”等）

那是一个周五的晚上，项目急着等第二天上线，我负责的部分就差最后一步：把一批预热数据刷到Redis里，本来以为就是个简单的SET命令，谁能想到,接下来几个小时我差点把键盘给砸了。

第一幕：诡异的“OK”与消失的数据

我像往常一样，用熟悉的客户端工具连接上测试环境的Redis服务器，敲下了命令：SET my_preheat_key "some_big_json_data"，命令行里赫然返回了一个“OK”！我心里一松，觉得搞定收工，可当我紧接着用GET命令去取的时候，返回的却是冰冷的(nil),数据根本没存进去！

知乎用户A的描述简直是我的嘴替：“当时我就懵了，明明返回了OK，就像你寄快递，快递员告诉你发出去了，但收件人却说从来没收到过包裹，这种‘薛定谔的存储’最折磨人。”

我开始怀疑人生，反复操作了好几遍，结果都一样——OK之后就是nil，我检查了网络，没问题；检查了Redis的日志，一片祥和，没有任何错误记录，那一刻，感觉Redis就像一个在对你微笑但背后藏刀的“老六”。

第二幕：内存，那个看不见的陷阱

在工位上来回踱步了十分钟后，我强迫自己冷静下来，既然简单SET不行，那是不是数据太大了？我试着SET了一个很小的值，比如SET test_key "hello"，这次居然成功了！能存也能取。

问题找到了方向：是我的数据太大，可我明明记得这台测试服务器的内存配置是够的呀，抱着试一试的心态，我执行了INFO memory命令，结果一看used_memory和maxmemory，心里顿时凉了半截——内存使用率已经接近100%了！

知乎用户B分享过类似经历：“我们当时也是，所有人都没动配置，但测试环境Redis莫名其妙就满了，后来才查到，是一个同事跑了一个忘记关掉的调试脚本，那个脚本在不停地往一个List里塞数据，像个水管漏水一样，悄无声息地把内存给撑爆了。”

我赶紧去查是哪些Key占用了大量内存，果然发现有几个早已不用的缓存Key，体积大得惊人，应该是之前某次测试后忘记清理了，我把它们删掉后，内存降了下来，再次尝试SET我的大JSON，这次终于成功了！我长舒一口气,以为噩梦结束了。

第三幕：配置里的“幽灵”

高兴了没五分钟，我换了一个Key名，准备SET第二份数据时，那个熟悉的“OK”后接(nil)的鬼故事又上演了！

“这不可能！”我几乎要喊出来，内存明明已经腾出来了啊，这次我真的有点崩溃了，开始漫无目的地翻看Redis的配置文件，一行一行地扫过去，一个参数引起了我的注意：maxmemory-policy allkeys-lru`。

这个配置的意思是当内存不足时，Redis会淘汰最近最少使用的键来腾空间，我瞬间明白了：我第一次SET那个大Key时，因为内存不足，触发了淘汰机制，Redis确实把我的数据写进去了（所以返回了OK），但可能因为它太大，或者由于LRU算法，在写入的瞬间，它自己或者另一个关键键就被立刻淘汰掉了！导致我紧接着去GET时，它已经“尸骨无存”了。

知乎用户C的评论点醒了我：“返回OK只代表命令被接收且语法正确，并不保证数据能持久地待在内存里，尤其是在内存压力下，配合淘汰策略，数据可能‘秒没’。”

即使我后来清理了内存，但只要我写入的数据大小接近或达到某个临界点，这种写入后立即被淘汰的“惨案”就可能再次发生，真正的解决方案是彻底调整maxmemory大小和选择合适的maxmemory-policy,而不是临时抱佛脚地删几个Key。

第四幕：连接池的“暗箭”

就在我调整完配置，以为万事大吉，开始写脚本批量灌数据时，新的问题又双叒叕来了，脚本运行中，偶尔会抛出连接超时的异常,导致部分数据设置失败。

这个问题更隐蔽，经过排查，发现是Redis客户端的连接池配置不当，当时项目用的一个老旧的客户端库，最大连接数设置得过小，而我的脚本并发量上来了，导致连接被耗尽,新的请求只能等待超时。

知乎用户D的痛苦回忆很相似：“我们那次性能测试，压到一半就大量报错，查了半天不是Redis服务器扛不住，是我们自己服务端的连接池满了！就像高速公路收费站只有两个口，车一多全堵死了。”

我不得不中途停下来，修改客户端应用的配置，增大连接池大小，并加入重试机制,这才让批量导入任务磕磕绊绊地跑完。

尾声：一场“惨痛经历”的教训

等所有数据终于安安稳稳地躺在Redis里，天都快亮了，这次经历让我深刻体会到，Redis设置值失败，远不是一句“命令写错了”那么简单，它背后是一个小型的系统工程,涉及到：

1. 服务器内存监控与规划：不能等到用满了才想起来。
2. 淘汰策略的理解：明白不同策略对业务数据的影响,OK不代表万事大吉。
3. 客户端配置的匹配：服务器再好,客户端配置拉胯也一样白搭。
4. 全面的监控告警：对内存、连接数等关键指标要有预警。

从那以后，我再也不敢轻视任何一次看似简单的“SET”操作，每一次失败的背后，都可能藏着系统某个环节的“债务”，这件事虽然让人头大和崩溃,但确实是一次代价惨痛却收获巨大的成长。