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

我一直在开发数据流/图表风格的内部DSP应用程序（Java w/hooks for Groovy/Jython/JRuby，通过OSGi的插件，大量的JNI），类似于纯数据和simulink。我目前的设计是推送模式。用户与某个源组件交互，使其将数据推送到下一个组件上，依此类推，直到出现结束块（通常是显示器或文件编写器）。这种设计有一些独特的挑战，特别是当组件缺少输入时。没有简单的方法可以请求更多的输入。我已经用反馈控制流实现了其中的一些功能，例如FFT块可以向其链的源块广播它需要更多的数据。我已经考虑添加对组件的支持，可以是push/pull/both

我正在寻找关于推拉和混合动力的优点的回应。你以前做过这个吗？什么是“陷阱”？你是怎么对付他们的？有更好的解决方案吗？

在大型产品中使用“主要拉动”方法的一些经验：

模型：节点构建1:N树，即每个组件（根除外）有1个父级和1..N个子级。数据几乎完全从父级流向子级。更改通知可以来自树中的任何节点

实现：发送节点的id和“生成”计数器通知所有LEAF。叶子知道它们依赖于哪个节点路径，所以它们知道是否需要更新。（任何其他子节点更新算法也可以，事后看来可能更好）

叶子查询其父对象的当前数据，递归地弹出查询气泡。由于包含生成计数器，因此气泡上升会在发起节点停止

优点：

• 父节点不需要关于其子节点的太多/任何信息。任何人都可以使用数据—这允许一种通用方法在用于显示的数据之上实现一些（最初不期望的）非UI功能
• 子节点可以聚合和延迟更新（避免重新绘制肯定比快速绘制好）
• 不活动的leaf不会导致任何数据流量

缺点：

• 由于发布了完整数据，增量更新的成本很高。 该实现实际上允许请求不同的数据包（以及 生成计数器可以防止不必要的数据流量），但最初设计的数据包非常大。切片只是事后的想法，但效果不错
• 你需要一个真正好的生成机制。最初实现的更新与初始更新（需要特殊处理-请参阅“增量更新”）和更新聚合冲突
• 数据在树上传播的需求被大大低估了
• 只有当节点提供对当前数据的只读访问时，发布才便宜。不过，这可能需要额外的更新同步
• 有时，您希望更新中间节点，即使所有叶都处于非活动状态
• 一些leaf最终实现了轮询，一些基本节点最终依赖于轮询。丑陋的

---

一般来说：

当数据层和处理层对UI一无所知时，数据拉动对我来说“感觉”更为自然。然而，它需要一个复杂的变化通知机制来避免“更新宇宙”

数据推送简化了增量更新，但前提是发送方非常了解接收方

---

我没有使用其他模型的类似规模的经验，所以我不能真正提出建议。回过头来看，我发现我主要使用了拉，这不太麻烦。看到其他人的经历会很有趣。

我在一个纯拉式图像处理库上工作。它更适合于批处理风格的操作，我们不必处理动态输入，因此它似乎工作得很好。Pull尤其适用于大型数据集和线程：我们可以线性扩展到至少32个CPU（当然，这取决于正在评估的图形）

---

我们有一个GUI，它允许叶子成为动态数据源（例如，一个传送帧的摄像机），它们通过丢弃和重建图形的相关部分进行处理。在我们的例子中，这是便宜的，所以开销没有那么高。

因为这主要是拉式的，所以树的根节点是流/链中的最后一个节点吗？是否可以有多个端点节点（多个显示器）？叶从其父节点拉出。（因此，总的流向是从根部流向叶片）。多个显示将是多个叶子。