推/拉数据流模型的优缺点是什么？

Question

我一直在以纯数据和simulink的方式开发数据流/图表风格的内部DSP应用程序（Java w/hook for Groovy/Jython/JRuby，通过OSGi插件，大量需要JNI）。我目前的设计是推动模式。用户与某个源组件进行交互，导致它将数据推送到下一个组件，依此类推直到结束块（通常是显示器或文件编写器）。这个设计有一些独特的挑战，特别是当一个组件需要输入时。有没有简单的方法来请求更多的输入。我已经用反馈控制流缓解了一些情况，例如，FFT块可以广播它需要更多数据来源化其链中的块。我已经考虑添加对组件的支持，可以是推/拉/两者。

我在寻找关于推拉vs拉杆/混合杆子的优点的回复。你以前做过吗？什么是一些“陷阱”？你是如何处理它们的？这个问题有更好的解决方案吗？

Answer 1

在大规模商品的“大多 - 拉”方法的一些经验：

型号：节点建立一个1：N树，即，每个组分（除了根）具有1个父和1 ..N个孩子。数据几乎完全从父母流向儿童。更改通知可以源自树中的任何节点。

执行：通过发送节点的ID和“生成”计数器通知所有叶子。 Leafs知道他们依赖哪个节点路径，所以他们知道他们是否需要更新。 （任何其他的子节点更新算法也会这样做，事后看来可能会更好）。

叶子查询他们的父母的当前数据，递归查询气泡。生成计数器包含在内，所以起泡停止在起始节点。

优点：

• 父节点并不需要太多的/他们的孩子的任何信息。数据可以被任何人使用 - 这允许通用的方法来实现用于显示的数据之上的一些（最初不期望的）非UI功能
• 子节点可以聚合和延迟更新（避免重绘确实节拍快速绘画）
• 不活动的叶子做不会造成数据流量在所有

缺点：

• 增量更新是昂贵的，因为完整的数据公布。 实现实际上允许请求不同的数据包（并且 生成计数器可以防止不必要的数据流量），但最初设计的数据包非常大。切片他们是事后想法，但工作正常。
• 您需要一个真正好的生成机制。最初实现的那个与初始更新（需要特殊处理 - 请参阅“增量更新”）和更新的聚合相冲突
• 需要数据传输up该树被大大低估了。
• 仅当节点提供对当前数据的只读访问时，发布才是便宜的。这可能需要额外的更新同步，尽管
• 有时您希望中间节点更新，即使所有叶子都不活动
• 某些叶子最终实现了轮询，但一些基节点最终依赖于此。丑陋。

---

一般：

数据拉“感觉”对我来说更原生时的数据和处理层竟然一无所知的用户界面。但是，它需要一个复杂的更改通知机制来避免“更新宇宙”。

Data-Push简化了增量更新，但只有当发送者非常了解接收者时。

我没有使用其他模型的类似规模的经验，所以我不能真正推荐。回顾一下，我发现我主要使用拉，这是一个麻烦。看到其他人的经验会很有趣。

Answer 2

我在纯拉图像处理库上工作。它更适合于批处理式的操作，我们不必处理动态输入，而且它看起来工作得很好。 Pull对于大数据集和线程特别适用：我们线性地扩展到至少32个CPU（取决于正在评估的图表，当然，呵呵）。

我们有一个允许树叶成为动态数据源的GUI（例如，提供帧的摄像机），并通过丢弃和重建图形的相关部分进行处理。在我们的情况下这很便宜，所以开销并不高。