为什么吞吐量和延迟与pub / sub系统成反比？

Question

在阅读a paper（非免费）比较Kafka和RabbitMQ时，我发现了以下内容（强调我的）：

  

延迟。在任何传输架构中，分组/消息的延迟都是   由串行流水线确定（即，处理步骤的顺序）   它通过了。延迟只能通过在一系列体系结构中对同一数据包同时工作的资源进行流水线传输来减少延迟（多个处理核心，磁盘或网络访问时的主DMA引擎......）。 不会因扩展资源而受到影响   平行。

     

吞吐量。传输架构的吞吐量是数量   每个可以传输的时间单位的数据包（或者字节）   生产者和消费者之间。与延迟相反，吞吐量可以   通过并行添加其他资源可以轻松增强。

     

对于简单的管道，吞吐量和延迟是相反的   成比例的。

为什么会这样？是不是说“（延迟）不受并行扩展资源的影响”？如果我添加更多机器来提高吞吐量，延迟如何降低？

Answer 1

让我们来看一下高速公路的情景，为了讨论的目的，我们将在华盛顿特区地铁中使用I-66。这条高速公路每天早上都有高峰时段的延误，大约需要40-60分钟的额外旅行时间。这是因为道路的吞吐量受到限制。结果，单辆汽车的延迟增加。

这背后的一般理论被称为Little's Law。它指出客户（或在这种情况下，驾驶员）在系统（即高速公路）中花费的平均时间量等于到达率除以系统中的客户总数。以代数方式表达，

这样做的实际意义是，考虑到汽车数量L的增加，例如高峰时段周围发生的事情，以及高速公路Lambda的恒定吞吐量（弗吉尼亚得到了一点点）创造性并弄清楚如何动态地将肩膀转换为交通车道，但它并不是非常有效），结果是增加了行进定义距离W所需的时间。 W的倒数是汽车的速度。

很明显，根据Little定律，吞吐量lambda与等待时间（时间）成反比，W对于恒定数量的汽车L。