3. 核心指标：延迟、吞吐量、可靠性、资源消耗的定义与权衡
做低延迟系统，说白了就是在四个指标之间走钢丝。
延迟、吞吐量、可靠性、资源消耗。这四个词，我几乎每天都要念叨几遍。很多刚入行的朋友喜欢追求单一指标的极致，比如「我要把延迟压到1毫秒以内！」——结果呢？资源消耗爆炸，吞吐量掉得没法看。
嗯，咱们今天就把这四个指标掰开揉碎了讲清楚。
3.1 延迟：一切设计的起点
延迟，就是数据从产生到被消费的时间差。在日志采集场景里，我习惯把它拆成三段：
- 采集延迟：日志从应用吐出，到被Agent捕获的时间
- 传输延迟：数据从Agent到中央存储的网络耗时
- 处理延迟：服务端解析、索引、落盘的时间
你想想看，用户感知到的总延迟，是这三段之和。哪一段都不能忽视。
核心观点：延迟优化要关注「尾部延迟」，而不是平均值。P99延迟才是用户体验的真实写照。
我在项目中遇到过一个问题：平均延迟只有2ms，但P99延迟飙到了500ms。查了半天，发现是GC停顿导致的。所以后来我做设计，一定会把P99/P999延迟作为硬性指标。
3.2 吞吐量：扛得住才是硬道理
吞吐量，单位时间内能处理的数据量。一般用QPS或MB/s来衡量。
这里有个常见的误区：很多人觉得吞吐量和延迟是线性关系。其实不是。我见过太多系统，在低负载时延迟表现完美，一旦压力上来，延迟直接崩盘。
为什么会这样？因为吞吐量达到某个临界点后，资源竞争会急剧加剧。比如：
- 磁盘IO排队
- 网络带宽打满
- 内存频繁GC
说白了，吞吐量和延迟之间，存在一个「甜蜜点」。我的经验是：设计时预留30%的吞吐量余量，用来应对突发流量。
3.3 可靠性：丢了数据是要背锅的
可靠性，就是数据不丢、不重、不乱序。在日志系统里，我把它分成三个层次：
| 层次 | 含义 | 实现方式 |
|---|---|---|
| At Most Once | 最多一次，可能丢 | UDP传输，无确认 |
| At Least Once | 至少一次，可能重复 | ACK机制，重传 |
| Exactly Once | 精确一次，不丢不重 | 事务日志，去重 |
避坑指南：我曾经为了追求极致延迟，用了At Most Once模式。结果线上出了故障，丢了整整10分钟的日志。排查问题时，数据对不上，那个痛苦啊……从那以后，我至少保证At Least Once。
可靠性是有代价的。每增加一次ACK确认，延迟就会增加一个RTT。每做一次持久化，IO开销就上去了。所以，你需要根据业务场景做取舍。
3.4 资源消耗：成本是硬约束
资源消耗，包括CPU、内存、磁盘、网络带宽。说白了，就是钱。
我见过一些团队，为了降低1ms延迟，把CPU利用率从40%干到了90%。结果呢？运维成本翻倍，还经常因为资源争抢导致服务不稳定。
我的建议是：
- CPU：控制在60%以下，留出余量应对突发
- 内存：尽量使用堆外内存，减少GC压力
- 磁盘：顺序写优于随机写，SSD优于HDD
- 网络：压缩传输，减少带宽占用
3.5 四者的权衡：没有银弹
这四个指标，就像四个角，你不可能同时做到极致。我习惯用一个三角形模型来思考：
你看这个图，资源消耗在中心。你想提升任何一个角，都得往中心投入更多资源。但资源是有限的，所以你必须做出选择。
我个人的经验法则是：
- 先定延迟目标：比如P99延迟不超过10ms
- 再压吞吐量：在满足延迟的前提下，最大化吞吐
- 保证可靠性底线：至少At Least Once
- 控制资源消耗：用成本倒推设计
小技巧：做性能压测时，不要只看平均指标。我习惯同时监控P50、P99、P999延迟，以及CPU、内存、IO的实时曲线。这样能快速发现瓶颈在哪。
3.6 实际案例：一个日志采集系统的权衡
我之前做过一个金融交易系统的日志采集。需求是这样的：
- 延迟：端到端不超过50ms
- 吞吐量：峰值10万TPS
- 可靠性：Exactly Once（交易日志不能丢，不能重复）
- 资源消耗：CPU不超过50%，内存不超过8GB
你看，这四个指标都很苛刻。怎么办？
我的方案是：
- 用Kafka做缓冲，利用其高吞吐特性
- 客户端批量发送，减少网络开销
- 服务端使用异步处理，避免阻塞
- 引入去重机制，保证Exactly Once
最终，延迟控制在30ms左右，吞吐量达到了12万TPS。代价是什么？内存消耗到了7.5GB，接近上限。但没办法，这就是权衡。
嗯，说到这，你应该明白了。低延迟设计，不是追求单一指标的极致，而是在四个指标之间找到最适合你业务的平衡点。没有银弹，只有取舍。
公众号:蓝海资料掘金营，微信deep3321