brpc1.15问题实录:bthread_worker_count取Node CPU，K8s缩容引发线程数超限

背景:

线上服务部署在 K8s 环境中，近期遇到一个诡异问题：一旦集群因cpu过低触发缩容，缩容过程中有些Pod cpu立马跑满100%，直接命中k8s cpu Limit 限制，而其他pod cpu则正常。更诡异的是，进行手动扩容后，部分Pod的cpu占用率一直无法下降，长期处于满负荷状态。该服务使用的brpc 框架版本为1.15。

场景复现:服务缩容触发时，线上的pod数量为8个，cpu使用率为40%，当8个pod开始缩容到6个时，其中每次会有1个到2个pod的cpu会突然飙升至100%，但其他pod的cpu使用率维持正常。

结论:

先给结论，修改了brpc启动的工作线程。让工作线程数量为pod limt cpu的3倍，目前在进行扩缩容时，尚未出现同样问题。但也不能完全确定已经解决，待后续继续观察。

修改工作线程方法(注: 一定要同时修改): 

启动参数

-bthread_concurrency=12

代码参数

brpc::ServerOptions options;

options.num_threads = 12;

排查:

从现象上看，感觉可能有两个方向需要排查。一个是aws云服务，承载pod的node节点是否稳定。另一个是brpc框架设置和业务代码是否存在问题。

第一感觉应该是自身代码的问题，所以先监控下cpu的相关情况。brpc有大量的内置监控，先从指标入手。翻阅官方文档:高效率排查server卡顿 | bRPC

发现brpc内部有4个指标需要特别关注的

bthread_worker_count: 工作线程的个数

bthread_worker_usage: 正在被使用的工作线程个数

system_core_count: cpu核心的个数

process_cpu_usage: 正在使用的cpu核数

到这其实算直接发现了一个问题，k8s容器上cpu limit是4，但bthread_worker_count监控出来却是32。查阅了一下源码，在默认情况下bthread_worker_count识别到的是物理机上的cpu数量。以下是自己的猜测，在程序缩容是，pod qps开始上涨，大量闲置brpc工作线程被激活，创建了大量的bthread，导致cpu飙升超出pod limit。

知识点:

bthread：用户态的“轻量级协程”，数量可以非常多（百万级）。它本身不直接对应操作系统线程，而是由调度器分配执行。

bthread worker: 真正执行代码的底层线程，每个 worker 都是一个 pthread（操作系统线程）。

关系:

1. bthread 运行在 worker 之上
每个 worker 线程内部运行一个调度循环，不断从全局队列或本地队列中取出一个 bthread 并执行它。
当 bthread 主动让出（如阻塞 I/O、等待锁、bthread_yield()）或时间片用完，worker 会切换到下一个可运行的 bthread。

2. M 个 bthread 映射到 N 个 worker

    M（bthread 数量）可以远大于 N（worker 数量）。

    每个 worker 在任意时刻只能执行一个 bthread，但可以通过快速切换来并发处理大量 bthread。

3. worker 不绑定 bthread

    bthread 在执行期间可能被不同的 worker 先后调度，没有固定关联。这保证了负载均衡和高效利用。