SCRAM-SHA-256高并发下CPU瓶颈源于每次连接需执行HMAC-SHA-256密钥推导和nonce校验，且PBKDF2默认4096次迭代；优化核心是减少完整握手次数，通过合理配置连接池、固定认证机制、调低scramIterationCount（如1024）及避免客户端重连抖动来摊薄开销。
为什么 SCRAM-SHA-256 认证在高并发下吃 CPU
不是网络或磁盘瓶颈，是每次连接都得做 HMAC-SHA-256 密钥推导 + 随机 nonce 校验，这俩操作纯 CPU 密集。10k 并发连接建立时，光认证阶段就能占满几核，尤其在小规格云主机上更明显。
-
SCRAM-SHA-256比SCRAM-SHA-1多一轮 PBKDF2 迭代，默认 4096 次 —— 这是可调的，但不能关 - 客户端重连（比如连接池没配好、超时抖动）会反复触发完整握手，比长连接复用开销高一个数量级
- MongoDB 本身不缓存认证中间态，每个新连接都从头算，没法靠加内存缓解
怎么降低单次连接的认证成本
核心思路：减少「必须走完整 SCRAM 流程」的次数，把开销摊薄到连接生命周期里。
- 强制启用
maxIdleTimeMS和minPoolSize，让驱动保持稳定连接池，避免频繁建连。例如 Node.js 的mongodb驱动设minPoolSize: 10、maxPoolSize: 50 - 禁用
authMechanism=DEFAULT自动协商 —— 显式指定authMechanism=SCRAM-SHA-256，避免驱动多一次试探性握手 - 确认 MongoDB 版本 ≥ 5.0，启用
connectionPoolMaxSize参数（服务端侧），配合客户端池控防雪崩 - 别在应用层做连接复用逻辑（比如自己 cache
MongoClient实例但没设maxPoolSize），这只会让认证压力更集中
要不要换 PLAIN 或 MONGODB-X509 机制
换不了，或者换了更糟。
-
PLAIN要求 TLS 加密通道（否则密码明文），且仍需服务端解密 + 查表校验，CPU 压力没本质下降，还多一层 TLS 开销 -
MONGODB-X509把负担转给证书签发和验证，OCSP 查询、CRL 检查、私钥解密全是 CPU 活，而且运维复杂度飙升，不适合快速扩缩容场景 -
LDAP绑定？延迟更高，依赖外部服务可用性，故障面扩大 —— 你扛不住并发，不代表 LDAP 服务器扛得住
真正有效的压测与调优点
别只盯着 mongod 的 CPU 使用率看，要拆开看哪块在烧。
- 用
mongostat --host localhost:27017 --authenticationDatabase admin -u user -p pass观察conn和auth列，如果auth占比持续 > 30%，说明认证确实是瓶颈 - 在 Linux 上跑
perf record -g -p $(pgrep mongod)，然后perf report，重点看scram_sha256_compute_client_proof和PBKDF2_HMAC的火焰图占比 - 调整
scramIterationCount：启动时加参数--scramIterationCount 1024（最低允许值），能降约 40% 认证耗时，代价是抗暴力破解能力略降 —— 对内网可信环境可接受
最常被忽略的是连接池配置和客户端重试策略。很多团队花时间调内核参数，结果发现只是 maxPoolSize 设成了 100，但实际峰值请求 200，剩下 100 个连接全在排队等认证 —— 这时候加 CPU 核没用，得先让池子够大、够稳。
