使用 Rails 让某些事情在特定时间发生
就像浏览器游戏一样。 用户建造建筑物，并为特定日期/时间设置计时器以完成建造并生成建筑物。
我想象有一个类似守护进程的东西，但是那会怎样呢？ 在我看来，旋转+轮询并不是正确的选择。 我查看了 async_observer，但这是否适合这样的事情？
Like with browser games. User constructs building, and a timer is set for a specific date/time to finish the construction and spawn the building.
I imagined having something like a deamon, but how would that work? To me it seems that spinning + polling is not the way to go. I looked at async_observer, but is that a good fit for something like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您只需要事件对拥有者可见，那么模型可以按需报告其更新状态，我们就完成了，继续前进，这里没有什么可看的。
另一方面，如果它需要从计划创建时起对任何人都可见，那么问题就更有趣了。
我想说你需要两件事。 一个队列，您可以将定时事件（数据库表就可以很好）和一个后台进程（连续运行或频繁重新启动）提取自上次执行以来计划发生的事件（或者我认为即将发生的事件）和行动他们。
查看 Rails wiki 上的选项列表，似乎没有一个真正的解决方案还没有。 让我们希望其中之一符合要求。
If you only need the event to be visible to the owning player, then the model can report its updated status on demand and we're done, move along, there's nothing to see here.
If, on the other hand, it needs to be visible to anyone from the time of its scheduled creation, then the problem is a little more interesting.
I'd say you need two things. A queue into which you can put timed events (a database table would do nicely) and a background process, either running continuously or restarted frequently, that pulls events scheduled to occur since the last execution (or those that are imminent, I suppose) and actions them.
Looking at the list of options on the Rails wiki, it appears that there is no One True Solution yet. Let's hope that one of them fits the bill.
我刚刚为我正在开发的 PBBG 做了这件事（Big Villain，你可以在 MadGamesLab.com 上看到正在进行的工作）。 不管怎样，我使用了一个命令表，其中每个用户命令恰好生成一个条目，以及一个事件表，每个命令包含一个或多个条目（链接回命令）。 使用 script/runner 启动的辅助守护程序定期轮询事件表并运行时间已过的事件。
到目前为止，它似乎运行得很好，除非我在向大量用户投入时看到一些问题，否则我不打算更改它。
I just did exactly this thing for a PBBG I'm working on (Big Villain, you can see the work in progress at MadGamesLab.com). Anyway, I went with a commands table where user commands each generated exactly one entry and an events table with one or more entries per command (linking back to the command). A secondary daemon run using script/runner to get it started polls the event table periodically and runs events whose time has passed.
So far it seems to work quite well, unless I see some problem when I throw large number of users at it, I'm not planning to change it.
在一定程度上，这取决于前端有多少逻辑以及模型中有多少逻辑。 如果您知道事情发生之前需要多长时间，您可以将大部分逻辑保留在前端。
我会使用您的模型来确定事物的状态，并且根据特定请求，您可以检查它是否已构建。 我不明白为什么你需要一个后台工作者来做这个。
To a certian extent it depends on how much logic is on your front end, and how much is in your model. If you know how much time will elapse before something happens you can keep most of the logic on the front end.
I would use your model to determin the state of things, and on a paticular request you can check to see if it is built or not. I don't see why you would need a background worker for this.
我将使用 AJAX 启动计时器（请参阅 Periodical Executor）来更新您的 UI。 在模型方面，只需跟踪建筑物的created_at列，并且仅在其构建时间已过时才允许使用它。 这样您就不必每隔几秒钟就去一次数据库来查看您的建筑是否已完成。
I would use AJAX to start a timer (see Periodical Executor) for updating your UI. On the model side, just keep track of the created_at column for your building and only allow it to be used if its construction time has elapsed. That way you don't have to take a trip to your db every few seconds to see if your building is done.