Node.js MongoDB连接重连逻辑处理

MongoDB客户端连接一旦断开，它不会自动恢复。很多开发者以为配置了 reconnectTries 就能高枕无忧，结果一旦遇到 topology was destroyed 错误，后续所有操作都会失败，只能手动重启进程来恢复。

MongoDB 客户端默认不会自动恢复已销毁的拓扑连接。一旦出现 topology was destroyed 错误，后续所有操作都会失败，必须手动干预或重启进程。

为什么 reconnectTries 和 reconnectInterval 不起作用？

这两个选项仅对“初始连接失败”生效，不适用于连接建立后因网络中断、mongod 停机等导致的拓扑崩溃。当连接池内部状态变为 destroyed 时，驱动会直接拒绝所有新请求，不再尝试重连。

• reconnectTries: 60 只在 MongoClient.connect() 第一次执行失败时重试 60 次
• 运行中拓扑被破坏（例如 mongod 停机 35 秒）后，reconnectTries 完全不触发
• 错误日志中反复出现 [MongoError: topology was destroyed] 就是该状态的明确信号

如何监听并主动重建连接？

被动等待没有效果，必须监听客户端事件，在拓扑断开时主动调用 client.close() 并重新 connect()，否则旧 client 实例会永远卡死。

• 监听 client.on('serverClosed', () => {...}) 或更通用的 client.on('topologyClosed', () => {...})
• 不要只监听 error：很多断连不会抛出 error，而是让后续操作直接报 topology was destroyed
• 重建前务必先执行 await client.close()，否则 connect() 会复用已损坏的实例
• 重连逻辑需添加防抖，避免在断连期间高频触发多次重建

生产环境推荐的连接初始化模式

将连接封装成可重入函数，配合指数退避与状态标记，比依赖驱动内置重试更可控。

let client = null;
let isConnecting = false;

async function connectWithRetry() {
  if (client && client.topology?.state === 'connected') return client;
  if (isConnecting) return new Promise(r => setTimeout(() => r(connectWithRetry()), 100));
  
  isConnecting = true;
  try {
    if (client) await client.close();
    client = new MongoClient(uri, { 
      reconnectTries: 1, // 初始连接失败时只尝试1次，由外层控制重试
      reconnectInterval: 1000
    });
    await client.connect();
    console.log('MongoDB connected');
  } catch (err) {
    console.error('MongoDB connect failed:', err);
    await new Promise(r => setTimeout(r, 2000)); // 指数退避起点
    return connectWithRetry();
  } finally {
    isConnecting = false;
  }
  return client;
}

• 每次调用 connectWithRetry() 都能确保获取一个健康的新 client
• reconnectTries: 1 是关键：禁用驱动内部重试，把控制权收回来
• 避免在路由层直接使用 client.db().collection()：应封装成 service 方法，内部自动处理连接异常

真正棘手的不是连不上，而是连上后断开、断开后还假装连接着——topology was destroyed 后 client 对象依然存在，但所有方法调用都会静默失败。必须通过 client.topology.state 或定期执行 client.db().admin().ping() 主动探测，不能仅依赖“它没有报错”。