任务 – TPL Dataflow vs普通信号量
|
我需要制作可扩展的流程.该进程主要具有I / O操作和一些次要CPU操作(主要是反序列化字符串).该进程在数据库中查询url列表,然后从这些url中获取数据,将下载的数据deserilize到对象,然后将一些数据保存到crm动态以及另一个数据库中.之后我需要更新第一个处理网址的数据库.部分要求是使并行度可配置.
最初我想通过一系列任务实现它,等待并使用Semaphore限制并行性 – 非常简单.然后我读了@Stephen Cleary的一些帖子和答案,建议使用TPL Dataflow,我认为它可能是一个很好的候选人.但是,我想通过使用Dataflow来确保我使代码“复杂化”,这是值得的.我也有一个建议使用ForEachAsync extension method也很简单,但是我不确定它是否会因为分区集合的方式而导致内存开销. TPL Dataflow是否适合这种情况？它如何比Semaphore或ForEachAsync方法更好 – 如果我通过TPL DataFlow在其他每个选项(Semaphore / ForEachASync)上实现它,我将获得哪些好处？ 解决方法
这几乎就是I / O.除非这些字符串很大,否则反序列化将不值得并行化.你正在做的那种CPU工作将在噪音中丢失. 因此,您需要关注并发异步. >正如您所发现的那样,SemaphoreSlim是此标准模式. ForEachAsync可以采用多种形式;请注意,在您引用的blog post中,此方法有5种不同的实现,每种实现都是有效的. “[T]这里有许多不同的语义可供迭代,每个都会导致不同的设计选择和实现.”出于您的目的(不想要CPU并行化),您不应该考虑使用Task.Run或分区的那些.在异步并发世界中,任何ForEachAsync实现都只是语法糖,它隐藏了它实现的语义,这就是我倾向于避免它的原因. 这使您可以使用SemaphoreSlim与ActionBlock.我一般建议人们先从SemaphoreSlim开始,如果他们的需求变得更加复杂(考虑他们会从数据流管道中受益),可以考虑转向TPL Dataflow. 例如,“部分要求是使并行度可配置.” 您可以从允许一定程度的并发性开始 – 其中被限制的事物是单个整体操作(从URL获取数据,将下载的数据反序列化为对象,持久保存到crm动态和另一个数据库,并更新第一个数据库).这就是SemaphoreSlim将成为完美解决方案的地方. 但是您可能决定要使用多个旋钮：比如说,您下载了多少个url的并发度,以及持久化的单独并发度,以及更新原始数据库的单独程度的并发性.然后你还需要限制这些点之间的“队列”：在内存中只有这么多反序列化的对象,等等 – 以确保具有慢速数据库的快速URL不会导致你的应用程序使用过多的问题记忆.如果这些是有用的语义,那么您已经开始从数据流的角度来解决问题,而这就是您可以更好地使用像TPL Dataflow这样的库. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |