LMAX 架构 - 数据增长

Question

考虑以下来自 LMAX 架构 description from Martin Fowler 的场景：

我将使用一个简单的非 LMAX 示例来说明。想象你是 用信用卡订购果冻豆。 <...>

在 LMAX 架构中，您可以将此操作一分为二。这 第一个操作将捕获订单信息并完成 向信用输出事件（请求的信用卡验证） 卡公司。然后业务逻辑处理器将继续 为其他客户处理事件，直到收到 输入事件流中的信用卡验证事件。处理中 该事件将执行该订单的确认任务。

因此，订单会一直保存在内存中，直到收到付款处理结果。

现在让我们假设我们有一个需要更多时间的步骤，而不是信用卡处理步骤，例如：我们需要执行库存检查，其中有人必须物理验证我们是否具有特定风味的果冻豆被订购。这可能需要一个小时。

如果是这种情况，是否会导致内存中保存的数据增长，因为可能有很多订单正在等待库存状态更新事件？

可能在这种情况下，我们需要从内存中删除订单并将其作为输出事件的一部分包含在内，外部系统（库存）负责生成另一个包含订单详细信息的输入事件。

我在这种方法中看到的问题是，我们不能将库存作为业务逻辑处理器的一部分。

关于我们如何解决这个问题的想法？

Answer 1

作为工作集的一部分，金融交易所中的工作订单可以保留几天甚至几个月。例如，等待期货合约到期。客户帐户也类似。 “工作集”是指当前处于活动状态的交易/订单/销售等。一旦交易完成，它就会成为历史数据的一部分。

内存系统现在非常大，即单个服务器中有数百 GB，几乎所有业务的工作集都可以轻松放入内存中。此外，可用内存大小的增长速度远远快于任何大型企业的增长速度。

您描述的场景并不是真正的问题。当您需要保存传统数据库或基于文件的系统更适合的所有历史数据时，可能会出现问题。

一个简单的练习是计算活动实体或工作集所需的内存，然后将其与现代服务器中可用的内存进行比较。可以在内存中保留数以亿计的活动实体。