问题标签 [akka-cluster]

我有一条消息通过 Akka 中的集群发送。我有两个后端节点和一个前端节点。后端节点正常，但前端节点没有出现（关联失败）。

我觉得我有一个关于为什么会这样的提示：我有一个工作配置（前端出现并且可以正常发送和接收消息），但是前端、后端和公共消息都在同一个包中。当我将这些拆分为单独的子项目（通用、前端和后端）时，代码会中断。有什么明显的原因吗？另外，堆栈跟踪：

我觉得这一定有一个明显的原因。我的 Build.scala 文件具有依赖项，并且我导入了我需要的类/对象，但是将它们放在单独的子项目中会影响什么吗？

Akka Cluster-Sharding 看起来与我必须跨 Akka 节点创建有状态持久性参与者的单个实例的用例非常匹配。

我不清楚是否有可能有一个需要参数来构造它的 Entry 演员类型。或者，也许我需要重新考虑 Entry 演员如何获取这些信息。

而ClusterSharding.start需要一个 Props 实例来创建所有 Entry Actor。

来自akka 集群分片：

然后它会根据您定义 idExtractor 的方式解析接收消息的 Entry Actor。从 shard 的源代码可以看出，它使用 id 作为给定 Entry actor 实例的名称：

}

看来我应该让我的 Entry 演员通过给定的名称来计算它的区域和 accountId，尽管现在我将从字符串中解析它而不是直接获取值，这确实感觉有点 hacky。这是我最好的选择吗？

我摸不着头脑，想弄清楚 docker、mess 和 marathon 的组合如何帮助我构建分布式应用程序。

应用程序有一个后端，由处理客户端请求和返回 json 数据的服务组成，这些服务由前端的 UI 层使用。服务需要具有高可用性和可扩展性。通过 REST 和 Web UI 支持用户交互。

如果有人能回答我的以下问题，我将不胜感激：

• 任何使用上述所有内容构建应用程序的示例/电子书/指南？
• mess/maraton 是否提供对集群的内置支持？或者您需要
  在容器中使用 akka 集群或 netty？
• 负载平衡如何与混乱/马拉松一起工作？
• 我的应用程序是这些技术的一个很好的用例吗？

谢谢

我正在使用 akka 集群 2.3.6

我编译了两个分开的罐子，里面我有主类

我正在运行两个单独的罐子：

我的 poc.conf 如下：

在 netty.tcp 内部阻止每个分配给端口 2551 和部分 2552 的第一个应用程序。

但是，当我启动两个 jar 时，每个 jar 都会打印以下日志：

我究竟做错了什么？

是否可以（以及如何）在配置文件中指定路由器的主管策略？所有示例都显示了如何以编程方式执行此操作。我的路由器是从配置文件中配置的。如果路由器配置在文件中也很好，但主管策略将在代码中配置。

另一个问题是，如果我使用集群感知路由器，情况会如何变化？是否可以为此类路由器提供主管策略

PS。还有一个与监督无关的问题：是否可以将构造函数参数传递给池化集群感知路由器的所有路由，以及如何（如果可能）？

在学习了一些教程之后，我想建立自己的与 Akka 聊天来玩一点。为了让事情变得更加困难，我也在尝试使用 IntelliJ IDEA 以及经过几年的 Eclipse。

我设置了一个简单的 POM 来获取 akka-cluster，启用自动导入并设置 IDEA 以支持 Scala（通过右键单击项目并在“框架支持”下启用 Scala）；我已经写了几行代码来开始工作。奇怪的是，当代码编译并正确运行（打印“hello, world”并退出）时，IDEA 报告我的代码有问题（我预计会导致编译失败的错误）。

这是我的 pom.xml：

这是代码：

IntelliJ IDEA 说 ActorSystem 导入是未使用的（尽管它被使用了），并且在几行之后它说它无法解析 ActorSystem.apply （尽管它确实如此，因为它可以正确编译和运行）。

此外，它突出显示了 Foo 的接收方法的右大括号，告诉我Expression of type Unit doesn't conform to expected type BoxedUnit.

我错过了什么？非常感谢你。

在这一刻，我有这个演员会话管理实现只在一个节点上运行：

1）我有一个SessionManager处理所有会话的演员

2）SessionManagerActor接收两条消息：CreateSesion(id)和ValidateSesion(id)

3）当SessionManagerActor接收到CreateSesion(id)消息时，它会创建一个SessionActorusingactorFor方法，如下所示：

context.actorOf(Props(new SesionActor(expirationTime)), id)

4）当SessionManagerActor接收到ValidateSesion(id)消息时，它会查找现有消息SessionActor并使用如下方法评估是否存在resolveOne：

context.actorSelection("akka://system/user/sessionManager/" + id).resolveOne()

使用该逻辑效果很好，但我需要在多个节点（集群）中实现相同的行为

我的问题是，建议使用哪种方法来实现该会话管理行为，以便它在一个或多个节点中工作？

我已经阅读了 akka 文档，它提供了akka-remote, akka-cluster, akka-cluster-sharding, akka-cluster-singleton，akka-distributed-publish-subscribe-cluster但我不确定哪一个是合适且最简单的方法。（请注意，SessionActor 是无状态的，我需要将它们定位在集群中的任何位置。）

我还没有遇到很多将 Play 与 akka-cluster 后端和像 Cassandra 这样的 NoSql 存储相结合的例子，所以我在实施这样一个系统时有些不确定性。

为了具体起见，我没有抽象地描述设置，而是提出了一个示例，它代表了 play 和 akka 可以大放异彩的一整类问题：

考虑：一个数据库支持的（让我们使用 Cassandra 集群）公路旅行应用程序，当您旅行时，它会推荐兴趣点。用户有帐户、输入设置和一些偏好。有一个旅行仪表板视图，包括旅行历史等。计划是使用 Play 和 Angular 的 web 应用程序，大多数 web 应用程序是从数据库中提取用户数据和 POI 数据并模板化、更新视图的简单案例。然而，计算和排名该区域 POI 的算法使 akka-cluster 和 actor 模型成为一个引人注目的解决方案。它需要用户数据（每天更新）和 POI 数据（按位置更新）作为输入，然后根据该数据运行算法。

总结： - 一个播放前端，提供请求，并调用由数据库支持的服务来满足请求（获取用户数据、模板等） - 一个 akka 集群后端，它从前端（或客户端）获取请求以排名积分基于用户数据（即偏好、年龄、历史）对该区域感兴趣的区域。这也需要通过参与者访问数据库。

讨论的一部分可能必然包括对所选数据存储最优化的内容，但这里是高级解决方案：

1. 将所有数据访问职责委托给 akka 集群，Play 仅将“获取一些数据”请求以及“基于数据 x、y 和 z 进行一些计算”请求转发到后端。这消除了多租户混淆

2. 将所有基本请求保留在播放端用数据存储数据填充模板，并将集群仅用于 cpu 密集型计算。播放前端转发计算请求。这意味着两者都可以访问 cassandra 集群（可怕吗？）

3. Play 应用程序只做计算，Akka-http 为客户端公开了计算 Api（角度，两个微服务都可以访问同一个 cassandra 集群

4. 使用 Akka-http 和 Angular 消除游戏并使其成为休息服务

对不起，如果这是一个太高级的问题。有什么想法吗？

我正在尝试构建一个双节点 akka 集群，并且两个节点都配置为种子节点。在每个节点上，我创建演员并通过以下方式定位它：

我期望的是我可以在任何节点上创建一个演员，只要我得到了它的单例路径，就可以在任何地方找到它。但是，结果是：getActor() 只在“leader”节点起作用，在其他节点不能识别。如果我对 clusterSingleton 有错误的理解？

我正在使用 Akka 的集群分片，如下所示：

idExtractor 和 shardResolver 设置为从消息中提取 ID 并将消息路由到集群中具有匹配 ID 的参与者。

这应该将所有具有相同 ID 的传入消息路由到集群中的同一参与者。不幸的是，来自设备的一半消息使用一个唯一 ID，其余消息使用不同的唯一 ID。两个唯一 ID 属于同一个设备，我想将两组消息路由到同一个参与者。将这些消息路由到集群中相同的相应参与者的最佳方法是什么？

我已经考虑过某种类型的键值存储来从两个单独的唯一 ID 中查找一个共同的唯一 ID，但我宁愿不引入单点故障。还必须对每条消息进行查找，这似乎不太理想。

能够为集群中的每个参与者分配多个身份以便协调器可以处理它会很棒。

更新

我想我有一个计划...

我将选择其中一个 ID 作为主 ID。我将使用辅助参与者系统将包含辅助 ID 的消息转发到主要参与者系统。次要参与者将存储设备的主要 ID 并使用主要 ID 将消息转发到主要参与者系统。

次要角色最初不会知道主 ID，但它可以在收到第一条消息时直接从设备请求主 ID。次要参与者然后将存储主要 ID 并使用存储的主要 ID 将未来的消息路由到主要设备参与者系统。

其他包含主要 ID 的消息将直接发送到主要参与者系统，无需通过次要参与者系统进行路由。