Kubernetes/Node+MySQL：并发请求指数级变慢致Pod崩溃问题排查求助

首先得说，你遇到的这两个问题——并发同路由请求变慢、大数据量路由导致Pod崩溃，都是Node.js+K8s+MySQL架构下非常常见的瓶颈场景，我帮你拆解根因，再给你一步步的优化方案：

一、先理清楚核心问题的可能原因 #

1. 并发同路由请求后续变慢 #

• Node.js单线程特性的坑：Node.js是单线程事件循环模型，如果你的后端没开集群模式，高并发下一旦有阻塞操作（比如慢查询、同步IO），所有后续请求都会排队，自然越跑越慢。
• MySQL连接池没配好：要是每次请求都新建MySQL连接，并发时连接数直接打满，建立连接的开销会拖垮整个请求链路；或者连接池的最大连接数设太小，满足不了并发需求。
• K8s Pod资源给少了：Pod的CPU、内存请求/限制设得太低，并发时资源被耗尽，K8s会给Pod限流，甚至调度延迟，请求响应自然变慢。

2. 大数据量路由导致Pod崩溃、超时 #

• Node.js内存溢出（OOM）：一次性把330行数据全加载到内存，要是每行数据结构复杂（比如带大文本、嵌套对象），很容易让Node进程内存超过Pod的限制，直接被K8s的OOM Killer干掉，Pod一重启，请求就超时了。
• MySQL查询太拉胯：查330行数据的时候没加索引，或者用SELECT *拉一堆没用的字段，导致查询时间太长，请求直接超时；而且大量数据传输也会占满网络和内存。
• K8s健康检查太敏感：存活/就绪探针的超时时间设太短，请求处理慢一点就被误判成Pod不健康，直接重启Pod，反而让站点更不可用。

二、针对性的优化方案 #

解决并发请求变慢的问题 #

1. 给Node.js开集群模式，榨干多核CPU
   Node.js内置了cluster模块，可以让进程利用服务器的多核CPU，把请求分散到多个worker进程里，避免单线程阻塞。给你个示例代码：

const cluster = require('cluster');
const numCPUs = require('os').cpus().length;
const express = require('express');

if (cluster.isPrimary) {
  console.log(`主进程 ${process.pid} 启动`);
  // 根据CPU核心数创建worker进程
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
  // worker崩溃自动重启
  cluster.on('exit', (worker) => {
    console.log(`worker进程 ${worker.process.pid} 崩溃，重启中...`);
    cluster.fork();
  });
} else {
  // 这里放你的Node服务代码
  const app = express();
  // 你的路由逻辑...
  app.listen(3000, () => {
    console.log(`worker进程 ${process.pid} 监听3000端口`);
  });
}

2. 优化MySQL连接池配置
   用mysql2或者sequelize这类支持连接池的库，合理设置连接池参数，避免每次请求新建连接：

const mysql = require('mysql2/promise');
// 创建连接池
const pool = mysql.createPool({
  host: '你的MySQL地址',
  user: '用户名',
  password: '密码',
  database: '数据库名',
  waitForConnections: true,
  connectionLimit: 10, // 根据Pod数量和MySQL最大连接数调整，比如MySQL默认max_connections是151，多个Pod要分摊
  queueLimit: 0 // 无限制排队
});

另外记得调整MySQL的max_connections参数，确保能支撑所有Pod的连接池总连接数。

3. 给K8s Pod加够资源
   先通过kubectl top pods看看Pod的CPU和内存使用情况，然后调整Pod的资源请求和限制：

spec:
  containers:
  - name: 你的Node应用容器名
    image: 你的镜像地址:标签
    resources:
      requests:
        cpu: "500m" # 0.5核
        memory: "512Mi"
      limits:
        cpu: "1" # 1核
        memory: "1Gi"

资源限制要够应对并发时的峰值使用，不然K8s会掐Pod的资源。

解决大数据量路由崩溃的问题 #

1. 别一次性加载所有数据，用分页或流式返回
   要么给接口加分页参数（比如page和pageSize），要么用流式响应，把数据分批返回，避免一次性占满内存。给你个Express流式返回的示例：

app.get('/large-data', (req, res) => {
  res.setHeader('Content-Type', 'application/json');
  res.write('[');
  let isFirstRow = true;
  // 用mysql2的流式查询
  const queryStream = pool.query('SELECT id, name, created_at FROM large_table').stream();
  
  queryStream.on('data', (row) => {
    if (!isFirstRow) res.write(',');
    isFirstRow = false;
    res.write(JSON.stringify(row));
  });
  
  queryStream.on('end', () => {
    res.write(']');
    res.end();
  });
  
  queryStream.on('error', (err) => {
    res.status(500).send(`查询出错：${err.message}`);
  });
});

这样数据是一点一点返给前端的，Node进程的内存占用会低很多。

2. 优化MySQL查询性能

• 给查询用到的字段加索引，避免全表扫描；
• 别用SELECT *，只查需要的字段，减少数据传输量；
• 用EXPLAIN分析查询计划，看看有没有走索引：

  EXPLAIN SELECT id, name, created_at FROM large_table WHERE category = 'xxx';
  

  如果type列是ALL，说明是全表扫描，得加索引优化。

3. 调整K8s的OOM阈值和健康检查

• 适当提高Pod的内存限制，比如从512Mi调到1Gi，同时监控内存使用，确认是不是内存溢出导致崩溃；
• 把存活探针和就绪探针的超时时间调长一点，避免误判Pod不健康：

  livenessProbe:
    httpGet:
      path: /healthz
      port: 3000
    initialDelaySeconds: 30 # 服务启动30秒后再开始探测
    periodSeconds: 10 # 每10秒探测一次
    timeoutSeconds: 5 # 探测超时时间设为5秒
  readinessProbe:
    httpGet:
      path: /healthz
      port: 3000
    initialDelaySeconds: 5
    periodSeconds: 5
    timeoutSeconds: 3
  

  记得在你的Node应用里实现/healthz接口，返回200表示服务正常，这样探针才会准确判断。

三、关于AB测试结果的分析建议 #

你提到了100次请求的AB测试结果，重点看这几个指标：

• 请求延迟分布：比如Time per request的平均值、中位数、95分位值，是不是长尾请求拖慢了整体速度；
• 错误率：有没有5xx错误，对应Pod崩溃的情况；
• 并发数：AB测试的-c参数是不是和生产场景一致，看看连接池能不能扛住。

如果能把AB测试的具体结果贴出来，能更精准定位问题，但上面的优化方案已经覆盖了大部分常见的根因。

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