推/拉數據流模型的優缺點是什麼？

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（例如，提供幀的攝像機），並通過丟棄和重建圖形的相關部分進行處理。在我們的情況下這很便宜，所以開銷並不高。