3. 并发模型深度解析：单容器多请求并发模型、请求队列机制、并发限制的实现原理
Knative 的自动扩缩容能力并非凭空而来，其底层依赖一套精心设计的并发模型。理解这一模型是进行容量参数调优的前提。本章将深入剖析 Knative Revision 实例（Pod）内部如何处理多个请求、请求队列如何工作，以及并发限制是如何被精确执行的。
3.1 单容器多请求并发模型
传统 Serverless 平台（如 AWS Lambda 的早期版本）通常采用“一个请求一个实例”的模型，导致冷启动频繁且资源利用率低。Knative 则默认采用单容器多请求并发模型，允许一个 Pod 内的用户容器同时处理多个 HTTP 请求。
核心思想： Knative 通过一个轻量级的反向代理（Queue-Proxy）作为 Sidecar 注入到每个 Pod 中，该代理负责拦截所有入站流量，并将其多路复用（Multiplexing）到用户容器，从而实现单容器并发处理。
下图展示了 Knative Pod 内部的并发请求处理架构：
3.2 请求队列机制
当并发请求数超过用户容器当前的处理能力时，Queue-Proxy 并不会立即拒绝请求，而是将其放入一个内部请求队列中。这个队列是 Knative 实现优雅排队和背压（Backpressure）的关键组件。
3.2.1 队列的工作流程
- 请求到达： 外部 HTTP 请求首先到达 Pod 的 Istio/ Kourier 网关，然后被路由到 Queue-Proxy。
- 并发计数： Queue-Proxy 维护一个原子计数器，记录当前正在被用户容器处理的活跃请求数。
- 入队决策： 如果活跃请求数已达到
container-concurrency限制，新请求被放入 FIFO 队列等待。 - 出队转发： 当用户容器完成一个请求后，Queue-Proxy 从队列头部取出一个等待请求，转发给用户容器。
- 超时处理： 如果请求在队列中等待超过
queue-proxy-timeout时间，Queue-Proxy 会直接返回 503 响应，避免请求无限堆积。
调优提示： 队列长度并非无限。默认情况下，Knative 会基于
container-concurrency 和 Pod 数量动态计算一个合理的队列深度。过长的队列会导致请求延迟增加，过短的队列则可能导致请求被过早拒绝。
3.3 并发限制的实现原理
Knative 的并发限制是通过 container-concurrency 参数控制的，该参数可以在 Revision 的 YAML 中设置。其实现机制是 Queue-Proxy 与用户容器之间的一个精确令牌桶模型。
3.3.1 并发限制参数
| 参数 | 默认值 | 说明 |
|---|---|---|
container-concurrency |
0（无限制） | 单个 Pod 允许的最大并发请求数。设置为 1 时模拟“一个请求一个实例”的模型。 |
queue-proxy-timeout |
600s | 请求在 Queue-Proxy 队列中的最大等待时间，超时后返回 503。 |
queue-proxy-queue-length |
自动计算 | Queue-Proxy 内部队列的最大长度，通常为 container-concurrency * 10。 |
3.3.2 精确控制流程
Queue-Proxy 通过 HTTP 响应头与用户容器进行“握手”，确保并发计数的精确性：
- 请求转发： Queue-Proxy 在转发请求前，会原子性地增加活跃请求计数器。
- 响应拦截： 用户容器处理完请求后，响应首先回到 Queue-Proxy。
- 计数释放： Queue-Proxy 在将响应返回给客户端之前，原子性地减少活跃请求计数器。
- 并发检查： 如果用户容器在处理过程中崩溃或挂起，Queue-Proxy 通过连接超时机制（
queue-proxy-timeout）强制释放计数，防止计数泄漏。
重要： 如果用户容器内部也实现了自己的并发限制（如 Java 的 Tomcat 线程池），请确保
container-concurrency 的值 大于等于 用户容器内部的并发上限。否则，Queue-Proxy 的计数将无法真实反映容器的处理状态，可能导致请求被错误地排队或拒绝。
3.4 并发模型对比
下表对比了 Knative 并发模型与传统模型的关键差异：
| 特性 | Knative 单容器多请求模型 | 传统单请求单实例模型 |
|---|---|---|
| 资源利用率 | 高（共享 Pod 资源） | 低（每个请求独占实例） |
| 冷启动频率 | 低（一个 Pod 处理多个请求） | 高（每个请求都可能触发冷启动） |
| 请求延迟 | 低（复用已启动的 Pod） | 高（冷启动延迟显著） |
| 并发控制粒度 | Pod 级别（通过 Queue-Proxy） | 实例级别（无并发问题） |
| 适用场景 | 高吞吐、低延迟、长连接服务 | 简单函数、对隔离性要求极高的场景 |