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