1 引言 一直以来，数据保护都是IT 行业和工业中(2)
2013-06-12 01:03
导读：对于传统流水线而言，要提高单一流水线的速度，必须把任务划分成很小的单元。例如： 现代CPU 的流水线通常有超过20 个阶段。然而，协同流水线一般由
对于传统流水线而言，要提高单一流水线的速度，必须把任务划分成很小的单元。例如：
现代CPU 的流水线通常有超过20 个阶段。然而，协同流水线一般由8 个子任务组成。包括把 bio 集合成组，压缩，加密，成组传输，解密，解压，写磁盘和回应。因为它是一个软件流水线，进一步的任务分解会导致交互开销过大。更何况我们不能准确地预知一些阶段的执行时间（主要是磁盘操作和网络传输，它们的性能很大程度上依赖系统的当前状态）。对于高效率的流水线来说，这是一个严重的阻碍。
一些典型的分布式流水线模型，例如流水线的高斯估测法[12]，将任务分解成相同大小的子任务，并把它们分发到合适的处理器上。然而在协同流水线中，每个子任务都有特定的“主人”，所以不能把它们任意分配给其他的处理器。例如：备份站点不能进行数据压缩，而必须有主站点完成。这个继承下来的不可变的任务映射使平衡负载变得困难。而且，即便我们把任务分成相同大小的子任务，处理器仍然会有空闲。此外，如果我们想通过加深流水线的深度来提高性能，我们就必须同等地进一步分解主站点和备份站点。
3.2 自适应成组传输
就像上面所提到的，在发送完前一个组后，主站点可以立即处理下一个组。在单用户系统中，这种“尽力而为”的策略保证了最优性能，但是它也有一些缺点。
如果两个站点的速度不同，例如，主站点比备份站点快，在“尽力而为”策略下，两个站点将会不同步。如果应用程序将压力加在存储子系统上，主从站点之间的裂隙将会越来越大，直到主站点用尽系统资源。然后主站点会放慢速度来等待备份站点的应答，好释放足够的资源。这样使用户体验很不稳定（主站点的应答时间）。此外，对于多用户系统来说，一个处理器用尽所有系统资源不是好方法。这会严重影响系统的稳定性和其他处理器的性能。
您可以访问中国科教评价网（www.NsEac.com）查看更多相关的文章。 总而言之，尽力而为的策略不能很好地协调主从站点的关系。或者，它通过用尽系统资源来“协调”两个站点。所以我们介绍一个自适应成组算法进行协调工作。当系统初始化时我们设置一个组间隔。这个间隔明确了请求积累和成组处理的时间段。即前一阶段积累的请求在下一阶段被成组处理。每完成一个组的操作，我们就会调整组时间间隔，使主从站点的执行时间接近。因此，当组间时间间隔最终达到稳定时，主从站点将有相同的执行时间（都和组间时间间隔相同）。值得注意的是磁盘操作和网络传输的执行时间不和组大小成比例。所以，虽然两个站点的时间间隔都变长或变短，但是增加迅速的那一方（通常是主站点）会比增长慢的那一方（通常是备份站点，包括磁盘操作和网络传输）时间间隔长，所以组间时间间隔是收敛的。
不同于尽力而为的策略，当主从站点步调不一致时，自适应成组算法使较快的站点睡眠一段时间而不立即处理下一个组，即减慢较快的站点的速度来促使两站点间保持平衡。这样做的优点是显而易见的：执行速度快的站点不会耗尽系统资源，因此不会系统中其他的处理器。另一个优势是自适应成组传输对网络状况有很好的适应性。如果网络波动，由于时间间隔的调整，主从站点可以自动并及时地适应网络速度。下面的自适应公式用来调整组间间隔。
公式中curr T 和next T 分别表示当前和下一个时间间隔， pri T 和back T 分别表示主阶段和备份阶段的执行时间。在我们的实现中， pri T 包括成组，压缩，加密和发送组花费的时间，back T包括传输分组，解密，解压，写磁盘和应答所需时间。α 和β 是值在0 和1 之间的调整因子。它们决定了组间间隔接近真实处理时间的快慢和流水线适应网络改变的快慢。面对持续的繁重的负荷，我们使用组大小的阈值来控制一个组中最大请求数目：
（转载自中国科教评价网www.nseac.com ）
其中total N 表示已经被处理的总的请求数量；total T 表示总的处理时间；也就是说，统计量评估处理能力，并且用来设置下一个阈值next N 。说明了自适应成组算法。当主阶段完成后，公式(1)用来调整组间间隔。如果住阶段时间比当前时间间隔短，主站点将会睡眠一段时间。当主站点接收到应答时使用公式(2)。
