1

我正在设计一个解决方案，它需要一批对象并将它们传送到一个队列中，以便异步/稍后处理。我的目标是针对delayed_job/resque/sidekiq 的解决方案，其中工作人员被编组/ yamled/任何内容到数据存储中并在单独的进程中处理。

所以，按照我的设计方式，我有这个工人，它接受对象 ID、它的类和必须在每个对象上运行的特定操作。为什么要存储 id 和类名？这些是易于编组的元素（字符串、整数），并且大多数数据存储对编组的数据有一定的限制（是的，列 TEXT 等）。到目前为止，一切都很好。

现在，罪魁祸首：看到那边的动作了吗？它不是方法标识符。它代表一个闭包（它将每个对象作为参数，并发挥其魔力）。这个闭包是一个 Proc，并且 procs (WHY, LORD, WHY????) 不可编组。

所以，这打乱了我的计划。我正在设计一种策略，在某处拥有一个单例标识符，并动态插入一个辅助隐藏方法，该方法返回闭包。因此，作业将使用 id、类名和此辅助方法标识符进行编组。当作业运行时，会在所有对象上运行该操作，最后我将从单例实例中动态删除此方法。为此，此标识符必须是唯一的，为此我使用了 proc 闭包的 object_id。到目前为止，一切都很好。问题是，通常后台队列在与将它们排入队列的进程不同的进程上运行作业。这意味着，当作业运行时，返回我的过程的动态注入方法不可用。

所以，我的问题细分为子问题：

  1. 如何有效地将一批对象排队以供以后处理，其中要对它们运行的​​操作不一定是现有方法？
  2. 如何解决proc编组？
  3. 如何建立进程通信（不使用一些 3rd 方技术消息队列，如果可能的话，只使用普通的 ruby​​）

有谁知道关于我的问题的其他策略？可能是共享内存、进程间通信等等？或者也许是“编组” procs 的策略？

更新：

我设计了一个使用 DRb 的解决方案，其中我分配辅助方法的这个单例对象作为 DRb 对象提供给外部进程。有向它添加危险的公共 API 的缺点。有人知道优点/缺点/替代方案吗？

4

1 回答 1

0

至于 2. 担心我必须通过“单人娱乐”来实现它。那是在我重新创建 Marshal.dump / Marshal.load 之后（不是 DRY！）

def recreate_singleton( obj )
  class << obj
    def method
    end
  end
  return obj
end
于 2013-03-22T15:47:46.633 回答