高并发场景下的性能挑战：连接数、吞吐量、延迟、资源竞争
咱们做PKI SDK的，心里都清楚一件事——证书签发的活，平时看着挺轻松的。可一旦流量冲上来，那场面就不一样了。我记得有一次在某金融机构的灾备演练中，我负责的签名服务突然被压到了每秒几万次的证书请求量。结果呢？CPU直接飙到95%，连接池瞬间被耗尽，日志里全是超时报错。
那会我盯着监控面板，说实话，手心是冒汗的。
高并发下PKI的问题，说白了就四个字：抢不过、等不起。连接数不够用，请求就得排队；吞吐量上不去，排队越排越长；延迟一高，客户端的超时重试又会反过来加重服务端的压力。最后，所有的线程都在争抢锁和内存，资源竞争让整个系统几乎陷入停顿。
我们先来逐一拆解这几个核心挑战。
连接数与文件描述符极限
每个TCP连接，在Linux上都是一个文件描述符。操作系统对fd是有上限的，默认1024。你可能觉得改大就行了，但真正的瓶颈在后面。
我曾在一个项目中调优过一台64核的服务器，把fd上限改成了100万。结果呢？机器确实撑住了，但我们的签名服务CPU全耗在了epoll的事件循环上，真正的签名计算反而抢不到时间片。
为什么？因为每个连接创建时，都需要分配内核缓冲区、套接字结构体，这些都会消耗内存。更重要的是，线程模型下，每个连接往往对应一个线程，线程的上下文切换开销非常夸张。
所以，合理的做法是让连接池保持在一个可控范围，比如几千到几万之间。超出部分，用请求排队等待的方式处理，而不是无限创建新连接。
吞吐量与延迟的博弈
吞吐量（TPS）和延迟（Latency），其实是同一个硬币的两面。你见过那种情况吗？为了压低单个请求的延迟，把并发线数调得很低，结果整体TPS上不去，平均延迟反而变长了。
我习惯用一个简单的公式来理解：
TPS = 并发线程数 / 平均响应时间打个比方，如果有100个并发线程，平均每个请求处理需要10ms，那TPS就是10000。如果我把线程数翻倍到200，但平均响应时间因为锁竞争变成了15ms，TPS反而降到了13333。你看，投入的资源多了，产出却只增加了那么一点。
这里有个避坑指南——不能只优化延迟而忽略吞吐，也不能只追求吞吐而忽略延迟的抖动。在我之前做过的某银行PKI项目中，我们牺牲了5%的平均延迟，换来了3倍的峰值吞吐，这个取舍是完全值得的。
资源竞争：锁、内存与IO
资源竞争发生在哪？无非三个地方：CPU、内存、IO。
CPU竞争：主要是锁。PKI里的私钥运算，很多会用互斥锁来保证同一时间只有一个人操作密钥。在高并发下，锁的争用会非常严重。我记得有一次排查线上问题，发现99%的线程都在等待一个RSA私钥的锁释放。你说气不气人？
内存竞争：对象的创建和GC。每签名一个证书，你可能会new出一堆对象。在Java里，频繁的young GC会暂停所有运行线程；在C/C++里，频繁的malloc/free会导致内存碎片和堆锁竞争。
IO竞争：磁盘IO和网络IO。尤其是CRL（证书吊销列表）的增量更新，如果全量加载，内存和IO都会炸。
| 资源类型 | 典型瓶颈 | 个人踩过的坑 |
|---|---|---|
| CPU | RSA/ECC运算线程争抢 | 私钥池太小，所有线程卡在锁上 |
| 内存 | 对象创建频率过高 | 每次签名重新构造CA证书对象，GC压力爆炸 |
| IO | CRL全量加载+磁盘I/O | IOPS打满，签名请求排队到超时 |
典型瓶颈：到底谁拖了后腿？
讲到这里，你可能会问：那到底哪个瓶颈最要命？
说实话，没有标准答案。不同业务场景下，瓶颈是完全不一样的。但我可以分享一个排查经验：先看CPU使用率，再看IO wait，最后看GC或锁竞争。
- CPU跑满但IO很低：问题在计算密集区，比如签名算法、哈希运算。
- CPU不高但IO很高：磁盘或网络是短板，比如CRL持久化太慢。
- CPU和IO都一般，但延迟很高：大概率是锁竞争或者线程阻塞了。
设计目标：你要压到多少才算合格？
聊完了挑战和瓶颈，我们来聊聊目标。高并发的PKI SDK，到底要达成什么标准？
我个人习惯用这五个维度来衡量：
- 高连接承载：单机支持至少10万级TCP连接，且不出现大量TIME_WAIT。
- 高吞吐：单机签名/验证的TPS要达到万级或以上（取决于硬件和签名类型）。
- 低延迟：P99延迟要控制在100ms以内，P999不超过500ms。
- 低抖动：延迟的方差要小，不能一会1ms，一会500ms。
- 资源均衡：CPU、内存、IO不能有某个资源被耗尽而其他资源还很空闲。
当然，这些不是你拍脑袋定的。我曾经接手一个项目，客户要求P99延迟30ms以内，但他们的CA私钥是4096位的RSA，单次签名就接近100ms。你想想看，这怎么可能？最后我们不得不换成ECC证书 + 硬件HSM加速，才勉强扛住。
好了，我们来梳理一下本章的知识结构。
这张图把整章的脉络串起来了。你会发现，所有的调优手段，最终都是反推回设计目标的——解决哪个挑战，打破哪个瓶颈，再用对应的手段去落地。
下节我会专门讲“私钥运算的高并发优化”，那是整个PKI SDK最硬核的环节。你可以提前想想：如果让你优化一个单线程的RSA签名，你会怎么做？