DRb 的可靠性如何？
使用 DRb 时是否需要考虑任何问题实现内存中消息队列并同步进程之间的操作？ 我听说它可能不可靠，但在网上没有找到任何证实这一说法的内容。
如果相关的话，这些将是在 Rails 应用程序环境中运行的进程，它将更新数据库中的模型。
Are there any issues to consider when using DRb for implementing an in-memory message queue and for synchronizing actions between processes? I heard that it could be unreliable, but haven't found anything on the web that confirms this assertion.
In case it's relevant, these would be processes running with a rails app environment that will update models in the database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DRb 已经相当成熟并且被广泛使用。 我不知道有什么会使其不可靠，但我不使用它作为消息队列
我想说，使用消息队列作为消息队列会更幸运，而不是使用 DRb 滚动自己的消息队列。 根据您的需求，有很多解决方案，memcacheq 非常容易交互，并且位于内存中，并且非常可靠。
DRb is pretty established and widely used. I don't know of anything that would make it unreliable, but I don't use it as a message queue
I'd say you'll have more luck using a message queue as a message queue, instead of rolling your own using DRb. There's a bunch of solutions depending on your needs, memcacheq is pretty easy to interact with, and is in-memory, and is pretty solid.
我个人使用 DRb 在我的 Web 服务器上的两个独立进程中运行，其中一个用于 执行几分钟-长计算，允许网站轮询和检查进度，另一个作为共享验证码服务器，具有自己的数据库连接，用于我的服务器上的各种应用程序。 在这两种情况下，我都没有遇到过 DRb 服务器失败的情况（除非是我的编程错误）。
即使 DRb 服务器确实发生故障，您也可以重新启动它，并且仍在运行的客户端将在下次需要通信时重新干净地连接。
I personally use DRb running in two separate processes on my web server one to perform minutes-long calculations, allowing the website to poll and check in on the progress, another as a shared captcha server with its own DB connection for various applications on my server. In neither case have I ever had the DRb server fail (except where it was a programming mistake on my part).
Even when the DRb server does fail, you can restart it and the still-running client will reconnect cleanly the next time it needs to communicate.