高并发架构里那些被忽略的暗坑

上周五晚上十一点，我还在跟一个诡异的超时问题较劲。订单服务P99延迟突然从80ms飙到2.3秒，QPS却没明显上涨。查了半天，数据库一切正常，最后在链路追踪里发现是微服务连接池配置不合理，线程池瞬间饥饿。

这几年做高并发系统，真正把人搞崩溃的往往不是宏大架构，而是藏在细节里的"暗坑"。尤其最近折腾向量数据库和vLLM推理服务，它们在高并发下的表现跟传统Web服务完全是两个世界。

从数据库到队列，延迟预算要倒着算

DBA的经历让我习惯先看数据流，再算延迟预算。方法是把整条链路拆成一段段"预算"，倒逼每一段达标。

比如推荐服务要求端到端200ms以内。倒着算：客户端网络+渲染50ms，网关和序列化20ms，RPC两跳各15ms，留给核心逻辑和存储的只剩100ms。其中业务计算20ms，剩下80ms必须让数据库、缓存、外部依赖全部搞定。

很多人正着设计：先写代码，挂数据库，测出慢再加缓存、上索引、调连接池。这种"打补丁"在低并发下能混，QPS一上来补丁就互相打架。倒着算延迟预算，能逼你在设计阶段就做对取舍。

连接池最值得吐槽。很多团队用默认配置，比如HikariCP最大连接数10，但微服务下同时调用四五个下游，每个给10个连接，上游一抖动线程全卡在等连接上，雪崩就是这么来的。我的习惯是给每个下游单独配连接池，用信号量隔离，不让一个慢依赖拖垮整个服务。

向量数据库的高并发是另一个物种

去年做RAG项目，我去评估向量数据库，以为跟MySQL差不多，压测QPS和延迟就行，结果完全不是一回事。

向量数据库性能跟数据维度、索引类型、召回精度强相关。同样128维embedding，HNSW索引下，Milvus和Qdrant的QPS能差三到五倍。关键看场景：数据量、写入频率、是否强一致、能否接受近似召回。

高并发下最大的坑是写入和查询的资源竞争。很多团队一边实时写入，一边高并发查询，索引构建把CPU打满，查询延迟爆掉。我们的做法是物理隔离：写入走异步队列批量构建索引，查询走只读副本。上线后查询P99稳定在15ms以内，写入延迟增加200ms，业务完全可接受。

还有个易忽略的点：内存管理。HNSW图结构纯内存，数据量大时内存占用是原始向量的好几倍。我们三千万条128维向量吃了近80GB内存，改DiskANN方案后降到20GB以内，但QPS掉了40%。典型的空间换时间，得按业务权衡。

vLLM推理服务的并发模型

最近负责基于vLLM的在线推理服务，并发设计跟传统服务完全不同。传统Web瓶颈在数据库和外部IO，vLLM瓶颈在GPU显存和计算单元。

vLLM的PagedAttention把KV Cache分页管理，大幅提升显存利用率。但有个隐蔽问题：prefill和decode阶段的资源抢占。prefill一次性计算所有输入token的注意力，计算密集型；decode逐token生成，访存密集型。大量请求同时到达时，prefill占满GPU计算单元，正在decode的请求延迟飙升。

我们的方案是在网关层做请求整形：按批次聚合并发请求，控制同时进入prefill的数量，给decode阶段设置更高调度优先级。另外max_num_seqs参数直接影响并发度，太大会显存溢出，太小浪费吞吐。多轮压测后，A10显卡上定为256，配合动态批处理，单卡QPS稳定在40左右，生成延迟控制在1秒内。

运维技巧：监控GPU的SM利用率和显存占用率要分开看。SM利用率高说明计算饱和，适当降低并发；显存占用高但SM利用率低，说明有浪费，可以调大max_num_seqs。

DevOps不是工具链，是反馈回路

很多人以为上了Jenkins、K8s、Prometheus就算DevOps了。真正做得好的团队，DevOps核心是反馈速度。

我们之前代码提交到上线要十几道流程，平均两天。高并发系统迭代被卡死，性能问题修复好了也要等两天才能上线。后来做了几件事：性能测试左移到CI阶段，每次提交自动跑基准测试，性能回退超5%直接阻断合并；灰度发布自动化，按错误率和延迟指标自动推进；监控告警关联代码版本，快速定位问题commit。

发布周期从两天缩短到四小时以内。高并发系统的稳定性不是靠上线前一次大测试保证的，而是靠快速迭代和快速回滚兜底。

写在最后

做高并发这些年，最大的感受是：架构设计不是画几张图，真正功夫在不起眼的配置参数、连接池大小、超时时间、重试策略里。DBA经历让我习惯关注数据层每个细节，向量数据库和vLLM的经历又让我意识到，不同技术栈的并发模型差异巨大，拿传统Web思维去套一定踩坑。

高并发这东西，纸上谈兵没用，得上手压测、上线观察、出问题复盘，循环往复，才能慢慢建立起那种"手感"。