TPL Dataflow——CCR 的后继

TPL Dataflow 是微软面向高并发应用而推出的新程序库。借助于异步消息传递与管道，它可以提供比线程池更好的控制，也比手工线程方式具备更好的性能。代价则是你需要遵循.NET 程序员并不太熟悉的一些设计模式。

一个数据流包含了一系列的“块（block）”。在之前的 CCR 中，每个块叫做一个端口（port），它可以是源数据，也可以是目标数据。通常需要将数据发送给一个传播块以让数据进入到数据流当中，所谓传播块就是实现了 ISourceBlock 与 ITargetBlock 的块。由于传播块也是源，因此它可以链接到其他目标或是传播块上。数据流以异步方式从一个块进入到另一个块当中，根据需要它通常在源或目标处进行缓存。

见名知意，TPL Dataflow 底层的基础设施是.NET 4 的 Task Parallel Library。与 TPL 一样，你可以使用客户化实现替换掉默认的调度器。开箱即用的实现就是.NET 的线程池系统以及使用了异步上下文的框架。如果你希望将数据流运行在特定的线程上时通常会使用后者，比如说使用数据流操纵 GUI 时。文档在这点上描述的并不是十分清楚，但似乎你可以每个块为基础设置调度器。如果真的是这样，那它真的是提供了一种优秀的方式将数据编排到 GUI 线程上了。

默认情况下，数据流已经针对性能进行了调解，实现方式也很棒，这意味着一旦激活了某个块，那么它就会继续处理数据直到运行完毕。为了防止某个块消耗掉所有可用资源，我们可以为其设置一个消息数限定值。如果设置了，那么块只会处理设定的数据量，然后就会终止当前任务并由下一个接管。

块可以使用贪婪或非贪婪的方式使用数据。当多个目标都在争夺同一个源的消息时，后者的价值就彰显出来了。比如说，在使用多个目标对同一源进行负载平衡时，你想要保证这些目标是非贪婪的，以免所有数据都进入到第一个贪婪的块当中。使用非贪婪方式的另一个原因是当消息被新版本替换掉时能够丢弃掉这些消息。Broadcast 块就能说明这个问题。它将每条消息提供给每个目标。如果目标不接受该块，那么在 Broadcast 块接收到下一条消息时它还是可用的。

现在来谈谈锁的问题，为了避免死锁，TPL Dataflow 采用了一个很有趣的设计。当某个块需要接收多个源的输入时，它会等待，直到所有源的数据都可用为止。这样，它将使用两阶段提交来保证确实从每个源获取到了数据。我们强烈推荐开发者使用这种机制，不要手工锁定工作流中的数据。

这种设计可能会导致竞态条件，尤其是与 Broadcast 这样的块联合使用时更是如此。本质上，该问题源自于一条消息被多个块发送并操纵了。既然块会干扰到调度器，那么将不变的数据类型作为消息会更加安全。

目前， TPL Dataflow Library 与 Async CTP 都可以下载了。

查看英文原文： TPL Dataflow – The Successor to CCR