NodeJS+Socket.io+Redis内存优化：连接断开后内存未释放如何处理？

先给你理清楚核心问题：Redis本身自带内存回收机制，但Socket.io集群方案里的连接元数据要是没被正确清理，才会导致内存蹭蹭涨。结合你碰到的Node.js内存泄漏+Redis内存没释放的情况，我给你拆解几个实操步骤：

一、先搞清楚Redis里存的Socket.io数据到底是什么 #

Socket.io用Redis适配器时，默认会把房间信息、连接会话、用户关联数据存在Redis里。你得先排查这些数据有没有被正确淘汰：

• 生产环境别用KEYS socket.io*（会卡），改用SCAN 0 MATCH socket.io*看看现存的键数量，对比当前在线连接数，判断是不是堆了一堆僵尸连接数据。
• 用TTL <具体键名>检查这些键的过期时间，如果没设置TTL，那断开连接的数据会一直赖在Redis里，内存不涨才怪！

二、给Socket.io的Redis数据强制加TTL（最关键的一步） #

很多旧版本的Socket.io Redis适配器默认不会给连接相关的键加过期时间，你可以在初始化适配器的时候手动配置：

const { createAdapter } = require('@socket.io/redis-adapter');
const { createClient } = require('redis');

const pubClient = createClient({ url: 'redis://localhost:6379' });
const subClient = pubClient.duplicate();

// 初始化适配器时设置键的过期时间，比如10分钟（600秒）
io.adapter(createAdapter(pubClient, subClient, {
  keyPrefix: 'socket.io:',
  ttl: 600 // 这里设置过期时间，单位秒
}));

这样哪怕客户端异常断开（比如网络突然断了没发disconnect事件），Redis里的相关数据也会在TTL到期后自动被清理掉。

三、用Socket.io的disconnect钩子主动兜底清理 #

有时候客户端正常断开，但Socket.io的钩子没触发或者适配器没及时同步，你可以手动在disconnect事件里做清理：

io.on('connection', (socket) => {
  socket.on('disconnect', async () => {
    // 手动移除socket所在的房间（如果适配器没自动处理的话）
    const rooms = Array.from(socket.rooms);
    for (const room of rooms) {
      if (room !== socket.id) {
        await pubClient.srem(`socket.io:rooms:${room}`, socket.id);
      }
    }
    // 删除socket对应的会话键
    await pubClient.del(`socket.io:sockets:${socket.id}`);
  });
});

不过要注意：新版本的Socket.io Redis适配器已经优化了这部分逻辑，除非你用的是很老的版本，否则可能不需要手动做，但如果内存还是疯涨，加这个兜底准没错。

四、给Redis本身配置兜底的内存淘汰策略 #

就算Socket.io的数据都加了TTL，万一有些数据漏了或者TTL设得太长，Redis本身也要有兜底的内存管理。你可以修改Redis配置文件或者用命令动态设置：

• 先限制Redis最大使用内存：比如redis-cli config set maxmemory 10gb（根据你的服务器内存调整）。
• 设置内存淘汰策略：推荐用volatile-lru（只淘汰带TTL的键），这样只会清理Socket.io的连接数据，不会动你的业务数据；如果想更激进一点，用allkeys-lru（内存满了就淘汰最少使用的键）。
  动态设置命令：

redis-cli config set maxmemory-policy volatile-lru

要是想永久生效，记得把这些配置写到Redis的redis.conf里，重启服务。

五、别忽略Node.js内存泄漏的连锁影响 #

你提到Node.js里每个Socket连接内存不释放，这可能会导致Redis适配器里的客户端连接没被正确关闭（比如Node.js的Redis客户端连接池没回收）。所以得同时解决Node.js的内存问题：

• 用node --inspect启动服务，打开Chrome DevTools的Memory面板，做Heap快照对比，看看是不是有socket对象被全局变量、未清理的定时器意外引用了。
• 确保Socket.io的客户端连接断开时，所有相关的事件监听器都被移除，避免内存泄漏。

关于你说的“实际与预期不符” #

如果刚测试发现Redis内存没按预期释放，先查这几点：

1. TTL是不是真的生效了？拿具体的键用TTL命令看看过期时间。
2. 客户端是不是真的触发了disconnect事件？比如移动端后台杀进程可能不会发disconnect，这时候就得靠TTL兜底。
3. Redis的maxmemory-policy是不是没配置？如果内存没到上限，Redis不会主动淘汰键，哪怕有TTL。

内容的提问来源于stack exchange，提问作者twb