为什么像带有徽章的stackoverflow这样的网站会使用某种类型的延迟作业来确定何时颁发新徽章？

Question

Stackoverflow有一个漂亮的徽章系统.我注意到的一件事是徽章没有立即被授予,但有时在符合标准后似乎有某种类型的延迟.我在其他一些有徽章的网站上也注意到了这一点.

据推测,这是因为他们正在使用延迟工作,定期扫描以查看是否需要颁发任何新徽章.我在这里也看到了这种方法:
如何实现徽章？

但是,我真的不明白为什么这是必要的,并且我赞成在我的实现中简单地建立一个系统,在执行相关操作后,例如发布新的注释,调用checkAwardBadge函数,检查是否用户符合新评论徽章的条件.

Speedwise,我认为所有相关的用户统计数据都会简单地存储在User的子模型中,比如UserStats,这样每次都不需要计算注释的数量,这只是一个简单的查询.

令我感到震惊的是,我所支持的系统应该快速且易于理解.在这里我是否缺少为什么有必要使延迟工作复杂化？

澄清:我计划有一个抽象类成就,每个实际成就都是成就的实现.每个成就都有一个checkAwardBadge功能,可以从控制器调用,如果我应该选择去那条路线,或者任何时候真的,可以调用延迟的工作来检查用户是否获得了某个徽章.因此,成就代码将全部集中.

Answer 1

您的实现可能适用于简单的场景(如您所描述的场景),但如果事情变得更复杂,您可以使用以下解决方案:

(3)只是一个例子:假设您有一个操作,如删除评论,不会触发任何徽章,但稍后您需要在用户删除评论时授予徽章,您必须返回查找所有代码删除一条注释并添加对checkAwardBadge的调用.想象一下,在更复杂的场景中. (2认同)
它不会扩展,因为当您有100,000多个用户和10,000,000个操作时,您必须在每个用户的每个查询操作之后敲击数据库.相反,如果您将工作卸载到(等待它)工作线程,那么该东西可以在后台运行并定期更新每个用户的徽章.例如,通过扫描自上次运行线程以来创建的活动等,它可以是智能的. (2认同)

Answer 2

虽然这只与你所描述的场景松散地相似,但我觉得讨论我们在工作中所做的事情可能有助于说明这种方法的部分原因.

我在一家实时算法贸易公司工作.我们软件的部分功能是处理来自供应商的市场数据.

现在,有些东西需要响应每个单独的市场价格而发生.我们运行分析,安全触发器在某些情况下生效,等等.但我们不惜一切代价避免做的事情是膨胀代码,这些代码会对所有这些"次要"逻辑的市场事件作出反应.

这里的原因是我们的数据来自数据供应商的网络,我们需要这些数据源自由流动而无需任何备份.我们的软件可以处理大约每秒10,000个市场价格.如果处理这些市场事件需要很长时间,那么饲料就会开始堵塞,我们尽快对市场作出反应的能力也会受到影响.

这样做的结果是我们处理新市场事件的代码非常精简.事件会更新价格,就是这样.至于需要为每个事件运行的所有其他逻辑:这是通过一个尚未由此逻辑检查的所有事件的队列定期发生的.

这允许我们有一个响应速度极快且不会备份数据的线程,而另一个线程处理传入事件并使用它们执行更重要的计算.通过这种方式将工作分成两部分可以使一切运行顺畅.

我承认这只与您的问题相关,但在我看来,不检查每个用户操作上与徽章相关的逻辑的原因很可能是相同的.您不希望通过在操作发生的精确时刻执行不太关键的逻辑来减慢服务器上的每个操作.一般策略是保持快速操作(即,基本上所有用户操作)并将更耗时的工作委托给可能经常运行但不适用于每个此类操作的辅助进程.