无法通过调优突破的 AWS 硬性限制

在动手调整任何一个 Aeron 参数之前，先认清你要面对的那堵墙。AWS 在 EC2 网络上施加了五项硬性限制。这些都是物理与基础设施层面的约束——再多的 Aeron 调优也无法突破它们。

道理很简单：在调优之前，先确认你没有撞上其中任何一个上限。如果一个系统已经被 PPS 上限卡住，或者运行在 90% 的利用率下，那么对它做调优只是把症状换个位置而已。

关于 Aeron 的传输层究竟如何在网络上搬运字节，请参阅 The Aeron Files。本页只聚焦于它周围的 AWS 上限。

1. PPS（每秒数据包数）

每个 EC2 实例都有一个数据包速率上限。不同的实例类型和规格有着不同的 PPS 限制，而且无论怎么调优，你都无法超过该实例的 PPS 上限。

PPS 最先卡住的，是小数据包、高消息速率的工作负载——这恰恰是低延迟交易流量的特征。如果你的吞吐量已经达到平台期，而带宽利用率仍然很低，那说明你受限于数据包速率，而非带宽。提升实例规格（或者把多条消息批量打包成更少、更大的数据包）才是唯一真正的解决办法。

2. 单流限制

单条流——也就是一个 5 元组——是有上限的：

VPC 内（标准情况）5 Gbps
CPG（Cluster Placement Group，集群放置组）内 10 Gbps

你可能需要多条流才能跑满可用带宽。一条绑定在单个 5 元组上的 Aeron stream，无论底层链路有多宽，都无法突破单流速率上限。

3. 带宽

PPS 和带宽是相互独立的限制。你可能先撞上其中任意一个。

Packet Per Second × Packet Size ≤ Bandwidth

这个公式要从两个方向来读。在小数据包尺寸下，PPS 是约束瓶颈，你永远逼近不了那个带宽数字。在大数据包尺寸下，带宽先成为瓶颈，而 PPS 处于空闲。把你真实的数据包尺寸分布画出来，对照这两个上限，看看你会先撞上哪一个。

4. 利用率与延迟的关系

与上面的 PPS 和带宽上限不同，这并不是一道硬性的物理墙——而是一个运行目标。对延迟敏感的单流 / 单核热路径，把带宽和 CPU 保持在 ≤ 60%，为抖动和微突发留出余量。这个数值落在更宽的 50–70% 排队拐点区间之内， ≤ 60% 是其中偏保守的一端。至于这个区间 为什么 存在——1 / (1 − ρ) 响应时间曲线、约 70% 的拐点，以及会抬高上限的情形（多核集群、批处理服务）——见传输性能影响因素。

在热路径上保守的理由是：平均值会掩盖突发。 一个”从未超过 80%“的 5 分钟平均值，仍可能掩盖某些核心被钉在 100% 持续数秒——而真正排队、把 p99 顶上去的，正是这些子区间的峰值，而非平均值。稳态数字会骗人： 90% 利用率在 p50 上看起来可能还不错，但只要遇到任何突发，就会产生糟糕的 p99。这部分余量并不是浪费，它正是用来吸收那些微突发的。

5. BDP（带宽时延积）

BDP 决定了在给定 RTT 下达到给定吞吐量所需的最小缓冲区大小。

Bytes in Flight = Bandwidth × Latency
  0.125 Mbit = 10 Gbit/s × 100 µs
  1.25  Mbit = 10 Gbit/s × 1 ms

如果把缓冲区设得低于 BDP，发送方就会因等待 ACK 而停顿，从而限制吞吐量。缓冲区大小随 RTT 线性增长，因此一个在同可用区（same-AZ）下正确的配置，到了跨可用区或跨区域时可能就会饥饿。

如何运用这些限制

把这五项当作一份起飞前检查清单。在伸手去拧任何一个 Aeron 旋钮之前，先把它走一遍：

我是不是受限于 PPS？ 吞吐量持平、带宽偏低 → 撞上了数据包速率上限。
我是不是受限于单流？ 在 VPC 内卡在 5 Gbps（或在 CPG 内卡在 10 Gbps）→ 把流量分散到更多条流上。
我是不是受限于带宽？ PPS × packet size 正在逼近链路速率 → 换更大的实例。
某个热路径资源是不是超过了约 60% 利用率？ 那么它的 p99 就只能听天由命，任由下一次微突发摆布。
我的缓冲区是不是低于 BDP？ 那么限制吞吐量的就是 RTT，而不是 Aeron。

把这五项全部排查清楚，然后再开始调优。关于这些上限之下的协议级机制，请继续阅读 The Aeron Files。