请注意以下说明仅供参考。问题是关于akka中事件流处理的模式，而不是关于如何用替代设计解决说明性示例的问题。
想象一下在Akka中编写的复杂事件处理引擎，其中事件规则由actor建模。消息的事件流程类似于订单，订单中的项目履行，订单付款。业务规则参与者正在执行类似于向客户开具发票和跟踪付款的操作，直到完成为止。业务规则感兴趣的数据本质上是非常动态的，其中不可能知道哪些规则正在跟踪消息流的哪些部分。
天真的人可以使用Boardcast路由器风格的方法。所有业务规则参与者都会看到所有数据，如果不是跟踪的数据，他们会忽略该消息。然而，这将具有可扩展性问题，因为并非所有规则参与者都对所有数据感兴趣的比例非常大。这意味着使用索引，规则参与者通过消息中的复杂业务标识符跟踪哪些类型的消息。然后我们只能向规则参与者发送他们正在寻找的数据。此索引的消息指向哪些参与者响应于参与者内的业务规则而更改。从路由演员的角度来看这个问题，然后他们想要动态地改变路线。
这引起了时间问题。如果路由actor运行得足够快以使许多路由忙，那么它将传递一个消息流，比如{A，B，C}，直到一个特定的路由器获得消息{A}。如果那个路由器然后决定它需要消息{B}那么它已经被路由到它的上游而不是路由到最近发现它的路由器的邮箱，它现在希望消息{B}看到消息{A}。修改后的路由只会在{C}之后的消息生效，或者更可能在路由参与者处理来自特定路由器的响应消息时更久。
对此的一个解决方案是在路由actor处缓冲消息。然后，如果一个routee改变了对响应消息感兴趣的内容，那么路由参与者可以扫描旧消息的缓冲区并根据需要重新发送一些消息。这意味着需要大量代码来保持消息缓冲区尽可能小，以便能够尽可能高效地重新发送它们。我想知道在Akka中是否有更标准的模式或更自然的方法来解决动态路由？
[脚注：评论中描述的替代解决方案是使用消息缓存并让规则actor命中缓存但是假设缓存必须非常大，强制IO或两个阶段提交主jdbc store假设如果可以避免，则不希望缓存。问题是关于akka中的事件流模式，其中路由规则可以以高度动态的方式改变 - 上面对这样的系统的近似描述被简化并且仅用于说明目的。关键的paragrah是关于消息流{A，B，C}并且路由读取{A}决定它然后需要已经由上游路由器调度的消息{B}。]
答案 0 :(得分：0)
这个问题似乎相当普遍。我在这里看到两个子问题
它可能会受益于规则分解。如果可以创建“关联令牌”（客户ID，初始订单ID），则某个中间参与者可以做非常好的初始路由（例如，基于令牌的哈希）。最后，终极演员可以从更小的一组消息中选择所需的内容。
为了构建具有复杂规则的通用事件处理拓扑，可以考虑使用库SynapseGrid。它有一个构建拓扑的构建器，然后转换为互连actor的运行时系统。这些规则要么像Scala函数一样简单，要么像带有嵌套actor的完整子系统分支一样复杂。