Socket.io+Redis Node应用升级后内存暴涨、连接异常求助

兄弟，我之前踩过几乎一模一样的坑——升级Socket.io、Redis这些依赖后，原本稳定的实时通知应用突然内存狂飙，100个用户连接就顶不住了。结合我的实战经验，给你梳理几个一步步排查的方向，应该能快速定位问题：

一、先拍实：连接数真的异常吗？ #

首先别上来就瞎调配置，先搞清楚是「真的连接没释放」还是「内存统计的误判」：

• 用Linux的netstat -anp | grep node或者Mac的lsof -i -P | grep node，看看Node进程的实际TCP连接数。如果显示的连接数远大于100，那肯定是连接泄漏没跑了；
• 同时在Socket.io代码里加个简单的连接计数日志，直接看服务端层面的连接变化：

  let activeSockets = 0;
  io.on('connection', (socket) => {
    activeSockets++;
    console.log(`新连接，当前在线：${activeSockets}`);
    
    socket.on('disconnect', () => {
      activeSockets--;
      console.log(`连接断开，当前在线：${activeSockets}`);
    });
  });
  

  如果用户断开后计数没减少，那就是disconnect事件没触发，大概率是心跳或者传输配置的问题。

二、查Socket.io升级后的默认配置变动 #

Socket.io v4+相对于旧版本改了不少默认配置，很多内存问题都是因为这个：

• 心跳超时配置：新版本的pingTimeout和pingInterval默认值可能更严格，或者和你客户端的配置不匹配，导致服务端没及时清理僵尸连接。手动设置回兼容旧版的配置试试：

  const io = require('socket.io')(server, {
    pingTimeout: 60000, // 60秒没收到心跳就踢掉
    pingInterval: 25000, // 每25秒发一次心跳包
    transports: ['websocket', 'polling'] // 确保启用的传输方式和客户端一致
  });
  

• CORS配置：升级后如果CORS没配对，客户端可能反复发起无效连接，导致连接数暴增。检查你的CORS设置，别用通配符*，指定具体的前端域名，并且credentials要开对：

  const io = require('socket.io')(server, {
    cors: {
      origin: "你的前端实际域名",
      credentials: true
    }
  });
  

三、盯紧Redis适配器——内存泄漏重灾区 #

Redis适配器是这类应用内存爆涨的头号嫌疑人，升级后要重点查这几点：

• 别在连接事件里瞎搞Redis：我之前见过有人把Redis客户端初始化、频道订阅写在connection事件里，导致每个用户连接都创建新的Redis客户端，内存直接炸。一定要全局初始化一次适配器：

  const { createAdapter } = require('@socket.io/redis-adapter');
  const { createClient } = require('redis');
  
  // 全局只创建一次发布/订阅客户端
  const pubClient = createClient({ url: 'redis://你的Redis地址' });
  const subClient = pubClient.duplicate();
  
  Promise.all([pubClient.connect(), subClient.connect()]).then(() => {
    io.adapter(createAdapter(pubClient, subClient));
  });
  

• 看Redis自身的内存：用redis-cli info memory查Redis的内存占用，如果Redis内存也跟着涨，那大概率是适配器没正确取消订阅，或者消息积压了。可以给Redis客户端加个日志，看看订阅的频道数是不是一直在涨。

四、用工具硬刚：抓内存快照找泄漏点 #

如果上面的排查都没头绪，就得上专业工具了：

• Clinic.js：Node官方推的性能分析工具，直接运行clinic bubbleprof -- node server.js，然后模拟100个用户连接，等内存涨起来后生成报告，能直观看到哪个函数在疯狂占内存；
• Chrome DevTools：启动Node时加--inspect参数，然后在Chrome里开chrome://inspect连接到你的Node进程，抓两次内存快照（连接前和连接后内存涨起来时），对比快照里的对象变化，找那些一直增长的对象——比如未释放的Socket实例、Redis的订阅回调等。

五、终极杀招：降级验证 #

要是实在找不到问题，就逐步降级依赖排查：

• 先把Socket.io降回之前的稳定版本，看内存问题是不是消失；
• 如果消失，再逐个升级Socket.io的子依赖（比如engine.io），定位是哪个版本搞出来的问题；
• 同理，降级Redis客户端（redis包）到旧版本，看看是不是Redis客户端的锅。

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