假设我们有一个反应式销售预测系统。
每次我们进行销售时，我们都会重新计算我们对未来销售的预测。如果有很多销售触发了我们的重新预测，这将非常有效。但是，如果销售额从每秒 100 个事件变为 0。并且长时间保持为 0，会发生什么情况？我们在销售良好时发布的预测仍然是最新的预测。
在这种情况下，您将如何模拟一个表示“没有销售发生”的事件，而不会退回到一些批量的每小时/每分钟/任意时间段事件，即“X 时间已经过去”。
这是一个通用问题的具体案例——在基于事件的系统中，你如何在没有发生任何事情的情况下模拟时间流逝——不使用会唤醒每个人重新考虑他们当前值的滴答时钟式事件[一个无法扩展的实现] .
我认为唯一有意义的选择是：每次我们进行销售时，我们还会在未来 2 小时内安排一个延期活动，要求我们重新考虑对该销售的评估。在处理该延迟事件时，我们可以选择安排进一步的延迟事件以供重新考虑。
考虑到这是一个非常通用的场景，您已经做出了一个相当大的假设，即除非一次完成一项销售，否则不可能设计出一种以可扩展的方式重新评估过去销售的设计。
场景中有许多不同的与规模相关的数字，您只查看单个预定预测更新程序可能尝试同时处理大量过去销售的数字。
我能想到的其他可扩展性问题：
如果您预计每秒有 100 次销售，那么重新评估每笔新销售的预测听起来并不好。如果您谈论的是用于会计的财务预测模型，那么如果组织每秒进行数百次销售，则不太可能每次组织进行销售时都需要更新它。
如果您谈论的是用于金融市场的短期预测引擎（即预测您在接下来的 10 秒内需要多少现金、能源或其他资源），那么听起来您有持续的波动性和您不太可能遇到几个小时内什么都没有发生的情况。如果您确实需要非常频繁地更新预测，那么在触发重新更新之前等待几个小时不太可能以您需要的方式为您提供所需的信息。
使用您的方法，您最终会为每种产品安排一个未来的预定活动（可能很大），并且每次进行销售时，您都会放弃旧的预定活动并安排一个新活动。因此，对于经常销售的产品，当您不太可能到达那里时，您将做重复性的工作以不断地将罐子推得更远。
什么构成一个好的设计将基于真实的场景。考虑通用案例很有趣，但是好的设计需要根据他们的情况进行塑造。
以下是我的一些想法，可能是合适的：
如果您希望在该产品有销售时更新每个产品的预测，但某些产品可以非常频繁地销售，那么一个好的方法可能是在每个产品的基础上限制或缓冲销售。如果一个产品每秒销售 50 次，您可能可以等待 1 秒、10 秒、2 小时等等，并立即评估所有这些销售，而不是每秒重新预测 50 次。尤其是如果您的预测过程很繁重，那么每次销售都进行预测可能会导致低价值的高负载，因为信息将在下一次销售时几乎立即过时。
您还可以有一个通用计时器来更新上一个窗口中尚未售出的所有产品的预测，但处理缓冲区中的产品。例如，您可以每小时挑选 10 种预测最早的产品并更新它们。这可以防止单个计时器在一次点击中重新预测整个产品集。
如果你想要一些简单的东西，你可以只使用上面的单一计时器方法，而忘记每次销售的预测更新。
如果您担心批量预测的负载，则应在与处理销售的硬件不同的硬件上完成此类工作。