流式事件和基于规则的触发器答案

【问题标题】：Streaming events and rule based trigger流式事件和基于规则的触发器
【发布时间】：2016-08-02 22:37:08
【问题描述】：

鉴于Event-A、Event-B、Event-C 在几天之内到达（可能出现故障），我想触发处理以生成派生 Event-ABC 一旦我知道我拥有集合中的所有事件.

事件按 userId/sessionId 分组

目前我从一个队列中读取所有事件，写入数据库，并更新元数据，说明哪些事件已被写入。一旦元数据包含基于规则的所有事件，我就会触发聚合处理。由于队列工作人员在处理属于同一组的事件时可能会敲击相同的键，因此这种方法存在一些性能问题，因此我正在寻找替代方案。

我想要的是更细粒度的软件定义路由和排队事件，基于他们的 userId/sessionId 进行处理。我认为我正在尝试做的事情有点类似于事件溯源。

我正在研究 Akka 是否可以帮助解决此类问题。对于每个 userId/sessionId 的参与者，它将减少不需要的并发性并在参与者中包含触发逻辑。我担心的是使用这么多 Actor 时可能需要大量内存。

【问题讨论】：

【解决方案1】：

您所描述的更类似于 Saga 或流程管理器，而不是事件溯源。您需要处理多条消息，然后在满足规范后做出反应的东西。

Akka 当然可以应付这个问题。使用 Akka，您可以为每个键创建一个 Actor，然后在收到消息时将消息路由到各个 Actor。我不会太担心内存问题，因为 Actor 系统应该处理成千上万的 Actor。我认为你需要衡量你得到的任何解决方案的性能。

您还需要考虑如何处理服务器崩溃 - 如果您将所有内容都保存在内存中，那么当服务器崩溃时您很容易丢失您的 saga。这可能是也可能不是问题，具体取决于您的要求（即您是否可以从中恢复）。如果考虑到这一点很重要，您可以查看 Akka Persistence。

【讨论】：

【解决方案2】：

这种方法存在一些性能问题，因为队列工作人员在处理属于同一组的事件时可能会敲击相同的键，因此我正在寻找替代方案。

免责声明：我不确定我是否理解您在此处描述的内容，因此以下解决方案可能不合适。

我认为我正在尝试做的事情有点类似于事件溯源。

是的，您的描述听起来很像来自 process manager 的事件。

事件处理程序（您可能对每种事件类型都有一个，或者订阅所有三种事件的单个处理程序）接收事件。

根据 userId/userSession 信息，它会为您的流程实例计算一个唯一标识符。想想哈希，或命名为 uuid，由进程的唯一标识符构建。

加载与标识符匹配的进程的当前状态。那是一种数据结构，用于跟踪以前见过的事件。它可能只是一个事件流。

apply当前事件到进程状态。如果这个事件已经被看到，“apply”应该是一个空操作——你的事件消息确实有唯一的标识符，对吧？

保存更新的进程状态。这将结束交易。

现在观察进程状态——您可以在事件处理程序或异步进程中立即执行此操作。如果流程“就绪”，则动词产生 Event-ABC。

上面的大纲遵循常见的模式，您有流程管理器来跟踪正在运行的流程的状态，但通过针对适当的聚合运行命令来触发业务逻辑。

在更简单的设计中，您可以将“聚合”和“过程”结合起来。基本模式是相同的 - 事件处理程序计算聚合的 id，加载它，并调用处理事件命令。聚合使用事件中包含的信息更新自己的状态，并将该状态更改写入自己的历史记录。如果考虑了所有必需的事件，则聚合还会将 Event-ABC 写入其自己的历史记录。

【讨论】：