gpt4 book ai didi

scala - 如果我有一个 Actor 应该有很大的吞吐量怎么办?

转载 作者:行者123 更新时间:2023-12-01 00:37:59 25 4
gpt4 key购买 nike

我有一个 Actor ,可以汇总一些信息并对其进行处理。它目前看起来像这样:

class MessageTracerActor extends Actor{

override def receive: Receive = {
case MyActor.TracableMessage(msg) => //send processed msg to another place
case v: Any => //corner-case, has special handler
}
}

参与者应该发送扩展 TracableMessage 的消息的踪迹。 .但是 TracableMessages由相当多的 Actor 发送并主持 MessageTracerActor在一台机器上不太好。

我看了 cluster shrading ,但情况似乎并非如此。他们说

Cluster sharding is typically used when you have many stateful actors that together consume more resources (e.g. memory) than fit on one machine. If you only have a few stateful actors it might be easier to run them on a Cluster Singleton node.



但是 Cluster Singleton 严格托管在一个不可扩展的节点上。

也许有一些配置选项可以指定用于处理参与者收到的消息的线程(甚至节点)数量?

最佳答案

有几个选项可以将消息处理扩展到单个参与者之外。

在单个节点中传播消息处理

如果跟踪消息处理是无状态的,您可以使用 routing 在跟踪消息处理参与者的多个实例之间分配工作。 .路由器是一个参与者,它建立一个处理参与者池,并在处理参与者之间分发每个传入的消息。

// create a round robin style router for actors
val router: ActorRef = context.actorOf(RoundRobinPool(5).props(Props[MessageTracerActor]), "tracer-router")

在上面的示例中,循环式路由器用于在跟踪器参与者之间均匀分配消息。这意味着您将失去发送到路由器的消息之间的排序保证:稍后入队的消息可能会在之前入队的消息之前处理。因为每个消息处理器只能看到传入消息的任意子集,所以也不能一致地完成像聚合这样的有状态处理。

为了使排序一致,您必须考虑哪些消息需要按顺序排列。如果所有可追踪的消息都需要按照它们进入路由器的顺序进行精确处理,那么路由器将无济于事。然而,一些可追踪的消息可能需要按照与某些消息相关的顺序进行处理,而不是其他消息。例如,您的可追踪消息可能包含消息的来源,并且排序必须仅在来自同一来源的消息之间得到保证。

确定消息之间的顺序允许您以一致的方式在消息处理器之间分发消息。 Akka 使用 consistent hashing pools 为此提供了功能。 .在一致性哈希池中,路由器根据哈希键机制将传入的消息分发给消息处理器。具有相同路由散列键的消息将被路由到相同的消息处理器,这意味着您可以一致地对传入消息的一部分可追踪消息进行聚合。

跨多个节点传播消息处理

如果一个 Akka 节点不足以处理可追踪的消息,您可以使用 Akka 的 clustering features 扩展消息处理。 .在集群中,您有多个 Akka 节点相互连接,通过跨集群分配工作而不是在单个节点中处理所有内容来协同工作。

在集群中,您可以使用前面描述的工具的分布式版本。对于消息的无状态和有状态路由,您可以使用 a cluster aware router .集群感知路由器创建跨集群成员节点的消息处理器池,而不是在单个节点中创建所有消息处理器。

除了集群感知路由器,您还可以使用 cluster sharding .就像在一致性哈希池中一样,您需要为集群分片指定一个哈希键,以便将消息一致地路由到正确的参与者。集群感知路由器和分片之间的区别在于分片自动为每个键创建一个actor,因此消息处理器actor不需要分别处理来自不同键的消息。

如果所有的可追踪消息都需要在同一个状态下聚合,你最后的选择是考虑 Akka 的 distributed data特征。在这个特性中,聚合工作分布在多个节点上,并在后期加入。请注意,分布式数据 API 在 Akka 2.4 中仍处于试验阶段。

其他需要研究的领域

跨多个节点分布消息处理意味着单个消息处理器丢失的风险更高(例如网络连接故障、节点崩溃)。为了保持节点之间状态的持久性和可转移性,您可能需要查看 Akka 的 persistence特征。

关于scala - 如果我有一个 Actor 应该有很大的吞吐量怎么办?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39120016/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com