线程还是 DRb？答案

【问题标题】：Threads or DRb?线程还是 DRb？
【发布时间】：2010-11-23 16:48:05
【问题描述】：

我需要有 2 个（或者可能是 3 个）连续运行 Ruby 程序的“方面”——一个通信线程、一个渲染线程，也许还有一个缓存线程。

这个想法是渲染线程显示幻灯片（其定义是从文件中读取的），并且所有幻灯片都由通信线程从远程 HTTP 服务器检索。渲染必须连续且不间断（因此可能需要缓存）。该文件可能会在程序的生命周期内发生变化，因此需要重新解析（动态）。

我想在“方面”之间发送消息，例如，当通信线程获取节目的整个“章节”时，渲染线程可以在等待整个节目下载之前启动，等等.

我应该使用 Ruby 线程还是 DRb？如何在线程之间传递消息？

感谢您的任何反馈！

【问题讨论】：

【解决方案1】：

一开始就保持简单 - 始终是最好的建议。从两个线程开始，看看性能是否是您需要的。您可以使用条件变量或简单的互斥锁来围绕检索到的章节列表进行同步。您可能会遇到欠载的问题 - 没有可用于渲染的章节，但您至少会掌握使用核心 Ruby 的可行解决方案的骨架。

然后，请务必考虑提供其他可能性的解决方案。除了 DRb，您还应该查看 EventMachine（阅读章节时可能需要的异步功能）和 RabbitMQ，了解消息系统提供的更通用和更松散的耦合。

从小处着手，不要尝试过快。对于任何关心 Ruby 线程的人，我正在运行一个小型报表呈现客户端，该客户端正在侦听 RabbitMQ 队列。客户端使用四个线程来渲染（google）图形、发送警报和自动重置各种队列（在收集了几个小时的数据之后）。一切都很好！

克里斯

【讨论】：

我只考虑 DRb，因为它具有消息传递功能 - 我不能用线程来实现它......对吗？我的意思是，我可以用互斥锁破解它，但它仍然是破解......对吗？ :) DRb 似乎容易多了。
只有在需要多个进程时才真正需要消息传递系统。听起来您不需要多个进程，因此我建议您保持简单。我正在做一些类似于你自己的事情（收集远程数据，处理它并渲染输出），一个简单的线程系统会很好用——我有一个用于每个阶段的线程和一个额外的线程——不需要 DRb。但是使用你认为你需要的东西！祝你好运！
恕我直言，RabbitMQ 建议是正确的方法。我之前用 DRb 和 RabbitMQ 都做过这种事情，DRb 解决方案不太理想。 RabbitMQ 的速度要快几个数量级，如果你使用 celldee 的 Bunny 库，它也容易得多。
实际上我正在使用 Bunny 作为我们解决方案的一部分，效果很好。