给定Event-A, Event-B,在几天之内到达（可能乱序），一旦我知道我拥有集合中的所有事件Event-C，我想触发处理以生成导数。Event-ABC
事件按 userId/sessionId 分组
目前我从一个队列中读取所有事件，写入数据库，并更新元数据，说明哪些事件已被写入。一旦元数据包含基于规则的所有事件，我就会触发聚合处理。由于队列工作人员在处理属于同一组的事件时可能会敲击相同的键，因此这种方法存在一些性能问题，因此我正在寻找替代方案。
我想要的是一个更细粒度的软件定义路由和排队事件，基于他们的 userId/sessionId 进行处理。我认为我正在尝试做的事情有点类似于事件溯源。
我正在研究 Akka 是否可以帮助解决此类问题。对于每个 userId/sessionId 的参与者，它将减少不需要的并发性并在参与者中包含触发逻辑。我担心的是使用这么多 Actor 时可能需要大量内存。
您所描述的更类似于 Saga 或流程管理器，而不是事件溯源。您需要处理多个消息，然后在满足规范后做出反应的东西。
Akka 当然可以应付这个。使用 Akka，您可以为每个键创建一个 Actor，然后在收到消息时将消息路由到各个 Actor。我不会太担心内存问题，因为 Actor 系统应该处理成千上万的 Actor。我认为你需要衡量你得到的任何解决方案的性能。
您还需要考虑如何处理服务器崩溃 - 如果您将所有内容保存在内存中，那么当服务器崩溃时您很容易丢失您的 sagas。这可能是也可能不是问题，具体取决于您的要求（即您是否可以从中恢复）。如果考虑到这一点很重要，您可以查看 Akka Persistence。
由于队列工作人员在处理属于同一组的事件时可能会敲击相同的键，因此这种方法存在一些性能问题，因此我正在寻找替代方案。
免责声明：我不确定我是否理解您在此处描述的内容，因此以下解决方案可能不合适。
我认为我正在尝试做的事情有点类似于事件溯源。
是的，您的描述听起来很像事件来源process manager。
事件处理程序（您可能对每种事件类型都有一个，或者订阅所有三种事件的单个处理程序）接收事件。
根据 userId/userSession 信息，它为您的流程实例计算一个唯一标识符。想想哈希，或命名为 uuid，由进程的唯一标识符构建。
加载与标识符匹配的进程的当前状态。这是一种数据结构，用于跟踪以前见过的事件。它可能只是一个事件流。
apply当前事件到进程状态。如果这个事件已经被看到，“apply”应该是一个空操作——你的事件消息确实有唯一的标识符，对吧？
保存更新的进程状态。这结束了交易。
现在观察进程状态——您可以在事件处理程序或异步进程中立即执行此操作。如果过程“就绪”，则动词产生 Event-ABC。
上面的大纲遵循常见模式，您可以使用流程管理器跟踪正在运行的流程的状态，但通过针对适当的聚合运行命令来触发业务逻辑。
在更简单的设计中，您可以将“聚合”和“过程”结合起来。基本模式是相同的 - 事件处理程序计算聚合的 id，加载它，并调用处理事件命令。聚合使用事件中包含的信息更新自己的状态，并将该状态更改写入自己的历史记录。如果考虑了所有必需的事件，则聚合还将 Event-ABC 写入其自己的历史记录。