泉州VPS服务器Redis异常如何修复?

说起来挺有感触的，上个月一个做跨境电商的朋友老陈，半夜十二点给我打电话。他在泉州东海那边自己搞了个工作室，主要做东南亚市场的鞋子批发。电话那头他声音都有点发飘了：“兄弟，出大事了，我的后台完全进不去了，用户购物车全空了，现在客服群里炸了锅，几百号人在骂。”

我当时远程连上他那台VPS，看了一下进程。Redis挂了。确切地说，Redis还在那里倔强地跑着，但它已经不干活了。CPU占用率突然掉到了一个很低的水平，内存却几乎被吃光，日志里密密麻麻全是“Cannot allocate memory”和“Connection refused”。

老陈当时都快哭了，他以为服务器被黑了。我让他先别慌，把Redis重启了一下，然后临时把session存储切换回文件模式。网站是恢复了，但速度慢得像老牛拉车。那一晚，老陈损失了不少订单，更重要的是，伤了几个老客户的心。

这件事让我印象很深。在泉州，做独立站、做小程序、做跨境电商的人非常多，VPS几乎是标配。Redis作为高性能的键值缓存数据库，大家几乎是“无脑装”。但很少有人真正想过，这个“红头发的家伙”一旦发起脾气来，到底怎么安抚?

今天，我就以那次帮老陈处理问题的经历为主线，结合几个在泉州本地遇到过的真实场景，把Redis异常修复这件事从头到尾说透。咱们不聊教科书式的理论，就聊怎么动手、怎么看、怎么救。

Redis崩了，症状到底长什么样?

很多人一听说Redis异常，第一反应就是“连不上了”。其实Redis异常的“花样”比你想象的要多得多，不同类型的异常，修复手段完全是两码事。

第一种最常见的，就是Redis进程直接挂了。 你敲命令redis-cli ping，它不给你返回PONG，而是直接报错“Could not connect to Redis”。这种情况通常是因为系统内存不足，Linux的OOM Killer(内存溢出杀手进程)把Redis进程给“干掉”了。或者Redis自身因为某些致命的错误导致崩溃。

第二种更隐蔽，叫半死不活状态。 进程还在，端口也还在监听，但你执行操作的时候，延迟高得吓人。本来一个GET操作只要零点几毫秒，现在动不动就几秒钟。你去看日志，会发现一堆“slow log”(慢查询日志)。这就好比一个人躺在那里，你喊他他睁眼看你一眼，但就是不动弹。

第三种是数据错乱或丢失。 最典型的，明明存进去的是字符串，读出来的是乱码。或者昨天存的数据，今天突然没了。这种问题通常跟持久化配置有关，比如你只开了RDB(快照持久化)，但上次保存快照失败了，重启之后数据就回到了上周的状态。

老陈那次遇到的，其实是第一种和第二种的结合。Redis进程没死透，但它因为内存碎片和交换分区的问题，陷入了频繁的SWAP(内存交换)，性能直接归零。说白了，就像一个人被埋在沙子里，能呼吸，但完全动不了。

泉州本地案例：三个翻车现场，三种修法

在过去一年多的时间里，我帮泉州本地不少做电商、做游戏、做API服务的朋友处理过Redis相关的故障。虽然病因各不相同，但复盘下来，核心问题其实就那么几个。

案例一：晋江某鞋厂官网的“内存大胃王”

晋江的一家鞋厂，自己搭了个官网，还做了个小程序用来展示新款。负责维护的是老板侄子，半路出家。他发现网站有时候会卡住，特别是下午三四点流量高的时候。他怀疑是带宽不够，结果加了带宽也没用。

我上去一看，Redis的used_memory_rss(实际占用的物理内存)比used_memory(申请的逻辑内存)高出将近一倍。这意味着什么?意味着内存碎片非常严重。就好比你租了个一百平的仓库，但里面隔墙太多，真正能用的只有五十平。

他家Redis的配置是默认的，没有设置内存上限，也没有设置内存回收策略。Redis就像一匹脱缰的野马，疯狂吞噬VPS的内存，直到把系统的剩余内存吃得一干二净。

修复过程其实不复杂。 第一步，通过redis-cli连上去，执行INFO memory命令，看清内存碎片率。第二步，动态调整配置，设置maxmemory为物理内存的百分之七十左右，留出一部分给操作系统和其他进程。第三步，设置maxmemory-policy为allkeys-lru，让Redis在内存不足时，自动淘汰最近最少使用的键。

重启Redis之后，碎片率从百分之两百多降到了接近一点零。那个鞋厂的官网再也没卡过。

案例二：泉州某游戏私服的数据“凭空消失”

这哥们更惨。他在泉州市区租了个场地，开了一个游戏私服，同时在线也就几百人。有一天服务器机房意外断电，来电之后重启VPS，发现玩家的装备数据丢了一大批，大家一夜回到解放前。

他百思不得其解，觉得Redis不是号称支持持久化吗?为什么一断电就丢了?我们检查了配置，发现他用的RDB持久化，快照间隔设置成了一小时一次。 也就是说，断电前五十九分钟的所有数据，都没来得及写入硬盘。断电的那一刻，内存一清空，数据就真没了。

修复方案有两套。 对于游戏私服这种对数据完整性要求极高的场景，RDB是不够的。我帮他改成了AOF(追加文件持久化)模式，并且把appendfsync设置成了everysec。这样每秒同步一次，最多损失一秒钟的数据。

另外，我还帮他配置了定期的BGSAVE和AOF重写，防止AOF文件变得过大。经过这次折腾，他学乖了，又加了一个从节点做冷备，每天自动备份一次RDB文件到单独的硬盘分区。

案例三：丰泽某电商团队的“连接数爆炸”

这是一个做直播带货的团队，在丰泽区的一个写字楼里。他们每次搞直播，流量瞬间能翻十倍。 Redis倒是不崩，但网站会时不时出现“Too many connections”的错误。

他们一直以为是VPS配置太低，准备砸钱升级。我看了看Redis的maxclients设置，发现还是默认的一万。按理说一万个连接数不小了，但他们用的是短连接，每打开一个页面就创建几十个Redis连接，用完也不及时释放。

再加上他们用的PHP程序，没有用连接池，每个请求都去新建一个连接。直播的时候并发请求一多，连接数就像脱缰的野狗一样往上窜， 直接冲破了操作系统的文件描述符限制。

修复这种问题，得从两头下手。 首先，在Redis配置文件里适当调整maxclients，同时别忘了修改/etc/security/limits.conf里的nofile参数，因为Linux系统本身会限制每个进程能打开的文件数量。其次，也是更关键的，改造程序代码。 让他们把短连接改成连接池，或者至少用pconnect(长连接)替代connect。

做完这两步，直播期间Redis的连接数稳定控制在几百以内，再也没出现过拒绝连接的情况。

修复实操：遇到Redis异常，按这个顺序排查

光说不练假把式。如果你现在手里的VPS上的Redis不对劲，又不知道从何下手，我建议你按照下面这个顺序来。这是我自己的血泪经验总结出来的。

第一步，别急着重启，先看日志。

很多人第一反应就是systemctl restart redis。这个习惯相当不好，因为重启会清空现场的“罪证”。正确的做法是，先去看Redis的日志文件。日志一般在/var/log/redis/redis-server.log。

你要找的关键词有这么几个：“OOM”(内存溢出)、“Misconf”(配置错误)、“RDB error”(快照错误)、“overcommit_memory”。这些关键词会直接告诉你问题出在哪一层。

第二步，看内存和连接数。

连上Redis，执行INFO命令。这个命令会输出一大堆状态信息。你不要被吓到，重点看三个部分。

看memory这一节里的used_memory_peak和mem_fragmentation_ratio。如果碎片率超过一点五，说明内存用得不太健康，可以考虑重启或者手动CONFIG SET调整。

看stats这一节里的total_connections_received和rejected_connections。如果拒绝连接数很大，那说明你的maxclients可能设置得太低了，或者你的程序没有及时释放连接。

看persistence这一节里的rdb_last_bgsave_status和aof_last_rewrite_status。如果这里显示失败，那你的持久化可能早就坏了，只是一直没发现。

第三步，检查操作系统的状态。

很多时候Redis的问题，根儿其实在操作系统上。用dmesg -T | tail -20看看内核日志里有没有Out of memory: Kill process的记录。如果有，说明Linux的OOM Killer出手了，你得考虑给VPS增加物理内存，或者减少Redis的内存占用。

再用free -h看看SWAP(交换分区)的使用情况。如果SWAP用了很多，那说明物理内存严重不足，Redis的部分数据被移到了硬盘上，速度当然慢。

第四步，对症下药。

如果进程挂了，先systemctl start redis拉起来，然后立即去改配置，把maxmemory调低，把overcommit_memory设成1。

如果性能慢得像蜗牛，而且你用SLOWLOG GET 10查到了很多慢查询，那就要看你的程序里是不是在乱用KEYS指令。KEYS *在高并发下是典型的Redis杀手，会阻塞整个服务。一律改用SCAN来迭代。

如果数据丢了，先别慌着恢复。先确定你的RDB或者AOF文件还在不在。如果都在，停掉Redis，把备份文件拷回工作目录，再启动。注意启动时日志里会显示载入了多少数据。

预防胜于修复：给泉州技术人的五点实在建议

经历了几次“救火”之后，我越来越觉得，Redis异常修复这件事，最好的方法就是不让它异常。

有几个小习惯，真心建议养成。

第一个，务必设置maxmemory。 不管你VPS内存多大，都不要让Redis无限制地吃下去。留有余地，是对系统和邻居最基本的尊重。

第二个，持久化要同时开RDB和AOF。 RDB适合冷备恢复，文件小速度快。AOF适合数据完整性，最多丢一秒。两个都开，双重保险。

第三个，定期做SLOWLOG检查。 一周看一次就够了。如果发现频繁出现慢查询，赶快去优化程序的调用方式。

第四个，别忽视监控。 哪怕只是写个简单的crontab脚本，每五分钟检查一次Redis能不能PONG回来。不能的话自动发个邮件或者微信通知。你能在用户发现问题之前，先把问题摁死。

第五个，学会优雅重启。 尽量不要用kill -9去杀Redis。用redis-cli shutdown save或者redis-cli shutdown nosave，让Redis自己完成收尾工作。

总结

回到文章开头那个问题：泉州VPS服务器Redis异常如何修复?

修复，从来都不是孤立的一个动作。 它不是敲一个重启命令，不是改一个配置参数，更不是盲目地升级服务器配置。修复是一个过程，是从发现症状、定位根因、执行操作再到事后复盘的全链条。

在泉州，我们的互联网氛围很务实，大家讲究的是“会做不如会修”，因为业务跑在线上，每一分钟的停机都是在烧钱。Redis这个“红头发”的兄弟，是个急性子。你对它好，给它足够的内存，帮它做碎片整理，给它设置合理的淘汰策略，它就能让你的网站快得像刺桐路上的跑车。

你对它敷衍，不设上限、不配持久化、不看日志，它就会在某个你最忙的深夜，给你来一次刻骨铭心的“意外”。

每一次异常，其实都是服务器在跟你对话。它在告诉你：要么内存不够了，要么程序写得太烂了，要么配置已经跟不上业务量了。

学会听懂Redis的“抱怨”，你就能在泉州这片创业热土上，把服务器跑得更稳，把生意做得更大。最后送大家一句话：不要等到Redis挂了才想起备份，不要等到用户跑了才想起修复。平常多看一眼日志，胜过半夜哭着求人。