为什么像 stackoverflow 这样带有徽章的网站会使用某种类型的延迟作业来确定何时授予新徽章？
Stackoverflow 有一个漂亮的徽章系统。我注意到的一件事是，徽章不会立即授予，但有时在我满足标准后似乎会有某种延迟。我在其他一些也有徽章的网站上注意到了这一点。
据推测，这是因为他们正在使用延迟作业，定期扫描以查看是否需要授予任何新徽章。我看到这里也建议采用这种方法：
如何实现徽章？
但是，我真的不明白为什么这是必要的，并且我赞成在我的实现中简单地建立一个系统，在执行相关操作（例如发布新评论）后，调用 checkAwardBadge 函数，该函数检查用户是否满足新评论徽章的标准。
Speedwise，我认为所有相关的用户统计数据都将简单地存储在 User 的子模型中，例如 UserStats，这样就不必每次都计算评论数量，而只是一个简单的查询。
我突然意识到我喜欢的系统应该是快速且非常容易理解的。我在这里是否遗漏了为什么有必要通过延迟工作使事情复杂化的缺点？
澄清一下： 我计划有一个抽象类成就，每个实际成就都有一个成就的实现。每个成就都会有一个 checkAwardBadge 函数，可以从控制器调用它，如果我应该选择走这条路线，甚至可以延迟工作，或者任何时候，检查用户是否赢得了某个徽章。因此，成就代码将全部集中。
Stackoverflow has a nifty badge system. One thing I noticed is that badges are not immediately awarded, but sometimes seem to have some type of a delay after I meet the criteria. I've noticed this on some other sites that have badges as well.
Presumably this is because they are using a delayed job that scans periodically to see if any new badges need to be awarded. I see this approach also advised here:
How to implement badges?
However, I don't really see why this should be necessary, and am favoring in my implementation to simply have a system where after a relevant action is performed, for example a new comment is posted, a checkAwardBadge function is called, which checks if the user meets the criteria for a new comment badge.
Speedwise, I was thinking that all relevant user stats would simply be stashed in a submodel of User, like UserStats so that instead of having to count the number of comments each time, it would just be a simple query.
It strikes me that the system I'm favoring should be fast and very simple to understand. Are there downsides I'm missing here on why it's necessary to complicate things with delayed jobs?
To clarify:
I plan to have an abstract class Achievements, with each actual Achievement an implementation of Achievements. Each Achievement will have a checkAwardBadge function, which can be called from the controller, or even a delayed job if I should choose to go that route, or any time really, to check whether a user has earned a certain badge. Thus, achievement code would all be centralized.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
虽然这只是与您描述的场景大致相似，但我认为讨论我们在工作中所做的事情可能有助于阐明这种方法的部分推理。
我在一家实时算法贸易公司工作。我们软件的部分功能是处理来自供应商的市场数据。
现在，需要采取一些措施来应对每个市场的变化。我们运行分析，设置在某些情况下生效的安全触发器，等等。但我们不惜一切代价避免做的是让使用所有这些“次要”逻辑对市场事件做出反应的代码变得臃肿。
这里的原因是我们的数据来自数据供应商通过网络，我们需要该数据源在没有任何备份的情况下自由流动。我们的软件每秒可以处理大约 10,000 个市场报价。如果处理这些市场事件需要太长时间，源就会开始堵塞，我们尽快对市场做出反应的能力就会受到损害。
这样做的结果是我们处理新市场事件的代码非常精简。事件更新价格，仅此而已。至于需要为每个事件运行的所有其他逻辑：通过尚未由该逻辑检查的所有事件的队列定期发生。
这使我们能够拥有一个响应速度极快且无需备份数据的线程，而另一个线程则处理传入事件并使用它们执行更重要的计算。以这种方式将工作分成两部分可以使一切顺利进行。
我承认这与您的问题无关，但在我看来，不检查每个用户操作的徽章相关逻辑的原因很可能是相同的。您不希望通过在操作发生的精确时刻执行不太关键的逻辑来减慢服务器上的每个操作。一般策略是保持快速操作（即基本上所有用户操作），并将更多耗时的工作委托给可能经常运行的辅助进程，但不是针对每个此类操作。
While this only loosely parallels the scenario you're describing, I feel that discussing what we do at my job might help illuminate part of the reasoning for this approach.
I work for a real-time algorithmic trading company. Part of what our software does is process market data from a vendor.
Now, there's stuff that needs to happen in response to every individual market tick. We run analytics, have safety triggers that take effect in certain cases, etc. But what we avoid doing at all costs is bloating the code that reacts to market events with all of this "secondary" logic.
The reasoning here is that our data comes over the network from a data vendor, and we need this data feed to be flowing freely without any back-up. Our software may handle somewhere around 10,000 market ticks per second. If it takes too long to process those market events, the feed starts to get clogged and our ability to react to the market as rapidly as possible becomes compromised.
The consequence of this is that our code that handles new market events is extremely lean. An event updates a price and that's it. As for all of the other logic that needs to run for each event: that happens on a periodic basis, via a queue of all events that have yet to be examined by this logic.
This allows us to have one thread that is extremely responsive and does not get backed up with data, while another handles incoming events and performs more significant computations with them. Splitting the work into two parts in this way keeps everything running smoothly.
I admit this is only tangentially related to your question, but it seems to me the reasoning for not checking badge-related logic on every user action could very well be the same. You don't want to slow down every operation on the server by executing less-than-critical logic at the precise moment the operation takes place. The general strategy is to keep your fast operations fast (i.e., basically all user actions) and to delegate more time-consuming work to secondary processes that run, maybe often, but not for every such operation.
您的实现可能适用于简单的场景（如您所描述的场景），但如果事情变得更加复杂，您将有一个解决方案：
Your implementation may work on simple scenarios (like the one you are describing), but if things gets more complex you have a solution that:
如果某个操作已完成并立即撤消，则可能不会授予徽章。
It could be so that if an action is done and immediately undone, it won't result in a badge being awarded.
我一直认为延迟是因为提供静态内容更快。我认为这在高流量网站上很常见，定期更新静态内容而不是为每个网络请求生成静态内容。
定期作业只会生成新的静态内容，并且会非常频繁地运行，但比每个页面请求的频率要低。
I always assumed the delay was because it is faster to serve static content. I think this is common on high traffic sites, periodically update static content instead of generating it for each web request.
The periodic job would just generate new static content, and would run very frequently, but less frequently than every single page request.