1 基本概念
1.1 定义
吞吐量是指系统、网络、设备或流程在单位时间内能够处理、传输或完成的对象数量。这里的“对象”可以是数据包、字节、请求、事务、订单，甚至是生产中的零件。它强调的是一段时间内真正完成了多少工作，因此常被理解为系统的实际输出能力。
在不同语境下，吞吐量也会被称为处理能力、产出速率或完成速率。与“能承载多少”相比，它更关注“实际做了多少”。因此，吞吐量往往需要结合统计时间窗口和具体口径来解释。
1.2 适用对象
吞吐量适用于多类系统和流程。计算机网络中，它可用于衡量链路或设备在一定时间内传输了多少数据。数据库系统里，它常用来描述每秒完成多少查询或事务。存储系统中，则用于表示读写数据的速度。
除了信息系统，吞吐量也广泛用于业务与制造场景。例如生产线每小时完成多少件产品、客服平台每分钟处理多少工单，都可以视为吞吐量的体现。只要对象可以被计数、完成或传递，就可以用吞吐量进行描述。
1.3 常见单位
吞吐量的单位取决于所衡量对象的类型。对数据传输而言，常见单位包括比特每秒、字节每秒；对业务处理而言，常见单位则是每秒请求数、每秒事务数等。单位不同，侧重点也不同。
1.3.1 比特每秒与字节每秒
在网络和存储领域，吞吐量常用比特每秒（bps）或字节每秒（B/s）表示。前者常用于传输速率，后者更便于理解实际数据量。由于 1 字节等于 8 比特，两者之间需要换算后再比较。
实际应用中，网络设备宣传性能时常使用比特每秒，而文件传输、磁盘读写或数据复制场景则更常使用字节每秒。为避免误解，阅读指标时应留意单位前缀，如 K、M、G 的具体含义。
1.3.2 每秒请求数与每秒事务数
在服务系统和数据库系统中，吞吐量经常用每秒请求数（RPS）或每秒事务数（TPS）表示。RPS 侧重接口或服务在单位时间内处理了多少请求，TPS 则多用于数据库或交易系统，强调事务完成数量。
这类单位更适合衡量业务处理能力，因为它们直接对应用户操作或系统任务。需要注意的是，请求和事务的复杂度可能差异很大，因此单看数量并不能完全反映实际工作量。
1.4 吞吐量与性能的关系
吞吐量是性能指标的重要组成部分，但并不等同于性能本身。一个系统吞吐量高，说明它在单位时间内完成的工作多，但这并不自动代表体验更好。若延迟过高或稳定性不足，整体表现仍可能较差。
通常情况下，吞吐量与资源利用率、并发能力和系统架构密切相关。优化性能时，工程人员会同时关注吞吐量、延迟和稳定性，以免只提升了“量”，却牺牲了“质”。
2 影响因素
2.1 资源限制
吞吐量往往受限于系统资源。任何一个关键资源出现瓶颈，整体处理能力都会下降。常见限制包括计算资源、内存容量、磁盘性能和网络能力。
2.1.1 CPU与内存瓶颈
当 CPU 运算压力过高时，任务排队时间会增加，系统处理速度随之下降。若程序大量进行加密、压缩、计算或复杂逻辑判断，CPU 往往会成为主要限制因素。
内存不足同样会影响吞吐量。频繁的内存分配、回收或交换操作，会带来额外开销，甚至导致缓存命中率下降。对于需要高并发和高速访问的应用来说，内存常是维持稳定吞吐量的重要基础。
2.1.2 磁盘与网络瓶颈
磁盘性能不足时，读写请求会积压，尤其在日志写入、数据库落盘和大文件传输中更为明显。顺序读写与随机读写的表现差异很大，因此“磁盘快不快”要结合具体访问模式判断。
网络瓶颈则常见于远程调用、文件分发和数据同步场景。当链路带宽不足、丢包率偏高或中间设备转发能力有限时，吞吐量会受到明显影响。此时，即使应用本身处理能力充足，也可能因传输环节受阻而无法释放全部性能。
2.2 并发与负载
并发程度和负载强度会直接影响吞吐量。适当增加并发，通常可以提高资源利用率；但当并发超过系统可承受范围后，争用、排队和上下文切换又会反过来压低效率。
2.2.1 线程数与连接数
在线程模型中，线程数增加并不总能带来吞吐量提升。若线程过多，调度开销和锁竞争会加重，反而可能降低整体效率。连接数也是类似道理，过多连接会增加管理成本和资源占用。
系统需要在并发能力与调度成本之间寻找平衡。不同架构对线程和连接的容忍度不同，因此最佳值往往需要通过测试获得，而不是简单套用经验数字。
2.2.2 请求大小与数据量
请求越大，处理和传输所需时间通常越长。小请求适合高频交互，大请求则更容易占用带宽、内存和 I/O 资源。数据量上升后，吞吐量可能先稳步提升，随后因资源耗尽而出现平台期甚至回落。
因此，评估吞吐量时不能只看请求个数，还要看每个请求携带的数据规模。相同的请求数，在不同负载下可能对应完全不同的实际工作量。
2.3 系统架构
系统设计方式对吞吐量有深远影响。架构决定了任务如何分配、数据如何流转，以及瓶颈会出现在何处。合理的结构往往能显著提高整体处理效率。
2.3.1 单机与分布式架构
单机架构实现简单，延迟较低，但资源上限明确，吞吐量容易受单台设备限制。随着负载增长，单机系统通常会在 CPU、内存、磁盘或网络上先后遇到瓶颈。
分布式架构可以通过多台机器分担压力，从而提升总体吞吐量。不过，它也引入了通信、协调和一致性开销。若设计不当，节点之间的同步成本可能抵消扩展收益。
2.3.2 缓存与队列机制
缓存可以减少重复计算和重复访问，从而提高吞吐量。对于热点数据，缓存命中率越高，系统越能把资源留给真正需要处理的请求。队列机制则可用于削峰填谷，在短时流量突增时缓冲压力。
不过，缓存和队列并非万能。缓存失效、队列堆积或消费速度不足时，系统仍可能出现拥塞。它们的价值在于改善流量分布，而不是无限抬高处理上限。
3 测量与计算
3.1 测量方法
吞吐量的测量通常依赖统计和测试两类手段。前者适用于真实运行环境中的长期观察，后者适用于实验条件下的性能评估。两种方法各有侧重，常常需要结合使用。
3.1.1 采样统计
采样统计是指在一定时间段内记录完成的任务数、传输量或事务量，再据此计算吞吐量。该方法适合监控线上系统，因为它能反映实际运行状态。
采样时需要明确时间窗口、采样频率和统计对象。若窗口过短，结果容易受波动影响；若窗口过长，细节变化可能被掩盖。因此，统计口径的一致性非常重要。
3.1.2 基准测试
基准测试通常在可控环境中进行，目的是比较不同系统、配置或版本的吞吐能力。测试人员会设定固定负载，观察系统在不同压力下的表现。
这种方法适合做横向对比，也便于定位瓶颈。但测试结果可能受环境影响较大，例如硬件差异、数据集规模和测试脚本设计都会改变最终结论。
3.2 计算公式
吞吐量的计算本质上是“完成量除以时间”。不过在实际应用中，还会根据窗口大小、峰值波动和统计对象进行调整，以获得更贴近业务的结果。
3.2.1 时间窗口法
时间窗口法是最常见的计算方式，即在某一时间段内统计完成数量，再除以窗口长度。例如某服务在 10 秒内完成 5,000 次请求，则平均吞吐量为 500 次请求每秒。
该方法简单直观，适合监控和报表展示。为了减少偶发波动，一般会使用滑动窗口或固定周期窗口进行连续观察。
3.2.2 平均值与峰值
平均吞吐量表示一段时间内的总体处理水平，更能反映长期稳定性。峰值吞吐量则表示在某一短暂时刻系统达到的最高处理速度，常用于展示理论上限或短时冲刺能力。
两者不能互相替代。峰值高并不意味着系统在高负载下能长期维持同样水平，平均值也可能掩盖短时拥塞。因此，完整评估通常需要同时参考这两个指标。
3.3 统计口径
统计口径决定了吞吐量“算什么、不算什么”。不同口径会得出不同结果，若不加说明，数字之间往往没有可比性。尤其在失败重试、部分完成和超时场景中，这一点尤为明显。
3.3.1 成功吞吐量
成功吞吐量通常只统计最终完成且结果有效的请求或事务。它更能反映系统真正提供给用户的有效产出，因此在服务质量评估中很常见。
这种口径较为严格，适合关注业务结果的场景。若系统中存在大量失败请求，成功吞吐量会明显低于总发起量，从而更真实地揭示可用能力。
3.3.2 含失败请求的口径
有些统计会把失败、超时或被拒绝的请求也纳入总吞吐量，强调系统在单位时间内“处理了多少输入”。这种口径适合分析压力测试或故障场景，因为它能显示系统接收并尝试处理的总体量。
但若不加区分，这类数字容易造成误解。因为“处理过”并不等于“完成好”，所以在比较不同系统时，应明确是否包含失败请求。
4 应用场景
4.1 计算机网络
网络领域是吞吐量最常见的应用场景之一。它用于衡量数据在链路、设备和协议栈中的实际传输能力。与标称速率相比，实际吞吐量更能反映用户感受到的网络表现。
4.1.1 链路吞吐量
链路吞吐量指某条网络链路在单位时间内实际传输的数据量。它受带宽、协议开销、丢包、重传和网络拥塞等因素影响。实际值通常低于理论上限。
在文件下载、流媒体播放和跨机房同步等任务中，链路吞吐量直接影响完成速度。评估时需要区分峰值瞬间速率与长期稳定速率。
4.1.2 网络设备性能
路由器、交换机和网关等设备的性能，也常通过吞吐量衡量。设备可以转发多少流量、支持多少并发连接，都会决定其适用规模。
若设备处理能力不足，可能出现转发延迟增加、丢包率上升或连接中断等问题。因此，吞吐量不仅是带宽问题，也关系到硬件转发和协议处理能力。
4.2 数据库系统
数据库中的吞吐量通常对应查询、更新或事务处理速度。对于高并发业务，数据库吞吐量往往决定整个系统的上限。
4.2.1 读写吞吐量
读吞吐量体现数据库每秒能够完成多少读取操作，写吞吐量则反映写入、更新或删除的处理能力。两者可能受不同因素限制，且优化方向也不完全相同。
例如，读操作常受缓存命中率和索引效率影响，写操作则更依赖日志、锁机制和存储性能。很多系统在读写混合场景下，读写吞吐量需要分别评估。
4.2.2 事务处理能力
事务处理能力强调数据库在单位时间内能完成多少完整事务。事务通常包含多个读写步骤，因此它比单次查询更能体现真实业务负载。
在交易、订单、结算等场景中，事务吞吐量尤其重要。它不仅要看完成数量，还要看事务的完整性和一致性，避免只追求数量而忽略结果正确性。
4.3 存储系统
存储系统的吞吐量主要描述数据读写速度，是衡量磁盘阵列、固态存储和文件系统性能的重要指标。
4.3.1 顺序读写吞吐量
顺序读写通常具有较高吞吐量，因为数据访问连续，磁头寻址或控制开销较小。大文件拷贝、视频写入和备份恢复等场景，往往更关注这一指标。
顺序吞吐量高并不意味着所有场景都快，因为很多应用并非连续访问数据。尽管如此，它仍是评价存储设备基础能力的重要参考。
4.3.2 随机读写吞吐量
随机读写更能反映存储系统在碎片化、小块数据访问下的表现。由于访问位置分散，额外开销通常更大，因此随机吞吐量常低于顺序吞吐量。
数据库索引、日志索引和小文件处理等任务，往往更依赖随机读写能力。对于这些场景，仅看顺序指标容易高估实际性能。
4.4 业务与生产流程
吞吐量不仅用于技术系统，也适用于业务管理和生产管理。凡是可以统计完成数量的流程，都可以借助这一指标进行分析。
4.4.1 工厂产能衡量
在工厂中，吞吐量可用来表示生产线单位时间内完成的产品数量。它反映设备、工艺、人员协作和物流衔接的综合效率。
若某个环节节拍过慢，就会形成瓶颈，限制整条产线的输出。因而，产能规划常以吞吐量为核心，结合良率和停机时间共同评估。
4.4.2 服务平台处理能力
服务平台中的吞吐量可用于衡量订单处理、客服响应、消息分发或任务调度能力。平台能在高峰时段稳定处理多少业务，是其容量设计的重要依据。
在实际运营中，平台通常需要兼顾吞吐量与体验质量。若短期内处理量很高，但用户等待时间过长，整体效果仍可能不理想。
5 相关概念
5.1 带宽
带宽通常指通信通道的理论传输能力或可用容量。它描述的是“最多能传多少”，而吞吐量更强调“实际上传了多少”。两者相关，但并不相同。
5.2 延迟
延迟是指请求从发出到完成所经历的时间。高吞吐量系统不一定低延迟，反之亦然。两者在某些场景下存在权衡关系。
5.3 响应时间
响应时间是用户或调用方感知到的等待时长，常包括排队、处理和返回多个环节。它与延迟接近，但更强调整体体验。
5.4 并发量
并发量表示同一时间内系统正在处理或等待处理的任务数量。适当提高并发有助于提升吞吐量，但超过承受范围后可能导致性能下降。
5.5 负载均衡
负载均衡是将请求分配到多个节点或资源上的机制。它可以避免单点过载，帮助系统更稳定地维持吞吐量。
6 优化方法
6.1 硬件优化
硬件升级通常是提升吞吐量最直接的方式之一。通过增强计算、存储或网络能力，可以扩大系统的基础处理上限。
6.1.1 升级处理器与存储
更强的处理器可以提高计算密集型任务的处理速度，更快的存储设备则能减少读写等待。对于依赖 I/O 的系统，使用更高性能的固态存储往往有明显效果。
不过，硬件升级的收益并非线性增长。若系统真正的瓶颈在软件或架构层面，仅更换硬件未必能显著改善吞吐量。
6.1.2 提升网络链路能力
增加链路带宽、优化网卡性能或减少传输跳数，都有助于提高网络相关吞吐量。对于分布式系统和数据同步任务，这类优化常常非常关键。
同时，还应关注协议开销和网络拥塞控制。否则，即使带宽提升，实际可用吞吐量也未必同步增长。
6.2 软件优化
软件层面的优化通常成本更低、可控性更强，是提升吞吐量的重要手段。它侧重减少不必要的开销，提高代码和算法的执行效率。
6.2.1 算法与代码效率
更高效的算法可以减少计算次数和资源占用。优化数据结构、减少锁竞争、避免重复运算，都是提升吞吐量的常见做法。
代码层面也可通过减少冗余对象创建、降低内存拷贝和缩短关键路径来改善性能。良好的实现方式往往能在不增加硬件成本的情况下带来明显收益。
6.2.2 缓存与批处理
缓存能够减少重复读取和重复计算，尤其适用于热点数据和高频请求。批处理则通过合并多个小任务，降低单次处理开销，提高单位时间内的完成量。
这两种方法都属于“用空间换时间”或“用聚合降成本”的思路。若使用得当，常能在不改变业务逻辑的前提下提升吞吐量。
6.3 架构优化
当系统规模扩大后，架构调整往往比局部修改更有效。通过重构任务分配和执行方式，可以更充分地利用资源。
6.3.1 水平扩展
水平扩展是通过增加节点数量来提升总体处理能力。相比单纯提升单机配置，这种方式更适合大规模并发和弹性增长场景。
它的优势在于可逐步扩容、容错性较好，但代价是系统复杂度提高。数据一致性、状态同步和调度策略都需要更精细的设计。
6.3.2 异步化与解耦
异步化可以让前端请求快速返回，把耗时操作交给后台处理，从而提高系统可承接的吞吐量。解耦则通过分离不同模块，减少彼此阻塞，使各部分能够独立扩展。
这类优化特别适合任务链较长、处理步骤较多的业务。它们能改善系统弹性，但也需要配合消息可靠性、重试机制和监控手段。
7 常见误区
7.1 只看峰值不看稳定性
峰值吞吐量往往是在理想条件下测得的短时结果，不能代表长期运行能力。很多系统在短时间内可以冲到很高数值，但一旦持续承压就会下降。
因此，评估时应同时关注稳定区间、波动幅度和持续时间。只有在真实负载下依然保持稳定的吞吐量，才更具参考价值。
7.2 混淆吞吐量与带宽
带宽是能力上限，吞吐量是实际完成量。前者偏“理论资源”，后者偏“实际表现”。如果把二者混为一谈，很容易误判系统性能。
例如，一条链路带宽很高，并不意味着传输过程中的有效吞吐量也高，因为还可能受到协议开销、丢包或处理瓶颈影响。
7.3 忽视延迟与用户体验
吞吐量提升后，如果单次请求变慢，用户体验未必改善。某些系统为了追求更高处理量，可能采用排队、合并或延后执行策略，从而拉长等待时间。
实际设计中，应将吞吐量与延迟结合考虑。对于交互型应用，响应速度往往和处理数量同样重要。
7.4 统计口径不一致
不同团队、不同工具或不同测试方法得出的吞吐量，若口径不一致，通常不能直接比较。是否包含失败请求、是否剔除预热阶段、时间窗口多长，都会影响结果。
因此，发布或引用吞吐量数据时，需要明确统计条件和计算方式。只有统一口径，指标才具有可比性和解释力。