软件管道规则

如果将步骤B进行分配是安全的，你可以简单地为它创建两个管道，使它的性能加倍，如图2.6所示，这将解决上述问题并可均衡事务流。

你可以从第1章回忆起管道分配器分配输入的消息到各个管道的过程。为了确定将每个消息向何处发送，它将会检验消息的内容，然后向匹配的、可处理该事务的管道发送。这种方法分配了负载，使你更多地控制了事物流。此外，分配器支持一些如同FIFO次序或优先级等关键业务需求。

另一个使用管道分配器的优点是能够可伸缩性。你可以赋予每个管道一个指定的硬件资源；分配器分配事务到每个管道中，每个管道独立且并发地执行各自的事务。如果硬件不足，这个管道就会成为系统瓶颈，你可以为这个管道添加资源。因为管道之间完全独立，添加更多的硬件资源也给管道带来了线性或近线性的扩展能力。

再进一步考虑，若分配器负担过多的管道，最终管道分配器自身会成为系统瓶颈。下一节，我们将展示如何使用规则3来避免这个问题。

2.9  规则3

管道分配器的处理速率要远远超过下游处理速率。

为了有效地实现管道分配器，你必须关注规则3。分配工作总是给系统带来一定的负担，因此管道分配器执行工作要比实际处理情况快很多才行。

规则3的公式是：

分配速率（）＞＞处理速率（）

换句话说，分配速率一定要比下游的处理速率快很多。如果不是，管道分配器自身将成为系统瓶颈，它会让整个软件管道架构失去意义。

在图2.8中，管道分配器为了避免成为系统瓶颈，必须拥有至少2000 TPS的吞吐能力。如果它能处理2000 TPS并且供给四个500TPS的管道，这样系统会工作的很不错。

图2.9  拥有负载逻辑的管道分配器会成为系统的瓶颈

如果你分配了太多的管道可能导致相反的问题。假设分配器可以处理2000 TPS，然而将步骤B的四个管道扩展为八个管道，如图2.10所示。
这种情况下，每个管道只能处理250 TPS，但是每个管道的处理能力是500 TPS。所以，这也是浪费了资源而且你没能对系统进行优化。
为了避免上述两种问题，使用下面的公式来决定对于系统中给定部分管道的最优化个数。

管道数量（）=分配器TPS/处理TPS（）

是理论下游执行管道的最大数目。你也可以认为这是对特定的处理过程做进一步的划分。是分配速率（管道分配器的处理速率），是下游处理速率（分配器供给的下游管道和组件的TPS总和）。对于系统某部，的比率是有效管道的理想数值。

当然，真实系统可能会出现一定的错误，因此你应做出一定冗余量，将管道数量提高10%到20%，确保系统有容错能力和足够流量。采用这种方式管道数量公式对于你的系统采用合适的管道数量和如何进行优化有着指导意义。

让我们看一个具体的例子。如果一个管道分配器的处理速率是1000 TPS，下游管道的处理速率为100 TPS，那么最大的管道数量是10。

这个系统将会比没有软件管道的系统快10倍。特别的是，在给定的时间内，这个系统将处理10倍于原来的事务数量。

管道数量公式向你展示重要的一点：系统必须以下游管道处理事务的速率向下游管道提供事务。否则，管道就会成为一个简单等待的没有任何收益的资源。

因此，最坏的场景是如果分配器评估和分配一个事务的时间比管道执行该事务的时间还长，你就不能从并发处理过程得到一点点的好处。事实上，分配器为处理过程带来一定不必要的消耗。当设计一个软件管道应用时，你的目的是最小化分配器带来的延迟（增加分配速率）并且尽可能多地为下游管道分派工作。

附加的一点是：第1章中提到你可以创建多层分配器与管道，任何管道都可以向分配器发送事务，为了从软件管道架构获得更多的益处，应用规则3与管道数量公式对于你的整个系统来说都很重要。

最近Cory担任Rogue Wave Software公司的总裁，3年来担任公司管理，建立新产品战略，并在2007年中期被一家私人控股公司成功收购。Cory关注的重点是有效地解决诸如SOA、可视化和支持实际业务应用的商品化资源的新技术开发和部署的挑战性问题。Cory具有高性能的事务处理应用的专业知识，帮助先进IT企业对数据与业务数量上的急剧增长做出响应，同时还解除了经营成本的压力。最近，Cory一直是在多核架构上为了改善应用程序性能而使用并行处理和可伸缩的数据库技术的积极倡导者。

Cory在美国加州圣巴巴拉大学获得学士学位。

内容简介：

《多核应用架构关键技术–软件管道与SOA》 介绍软件管道如何工作，它们能完成什么样的任务，如何使用软件管道优化周期来应用它们。通过并行处理方法，扩展保证关键任务处理有序的应用程序。解决现存应用程序的性能问题，并且解决现存处理过程中的瓶颈问题。一个完整的、容易采用的管道参考框架。详细的代码示例反映了经过验证的管道模式。 本书适用于开发多核环境下软件的人员。