【发布时间】：2020-02-03 10:49:14
【问题描述】：
我最近开始使用 akka 事件溯源/集群分片进行开发，感谢在线资源，我想我了解了基本概念以及如何使用它创建一个简单的应用程序。然而，我正在努力将这种方法应用于稍微复杂的数据结构：
以网页和 URL 为例。 每个页面都可以用集群中的一个参与者来表示（将其唯一的 id 作为页面的路径，例如 /questions/60037683）。
在每个页面上我都可以发出诸如
之类的命令- 创建页面（所以如果页面不存在，就会创建）
- 编辑页面（编辑页面详情）
- 获取页面内容（和子项）
等等
向单个页面发出命令时，一切都很简单，因为它“写在手册上”。但是我增加了网页可以有子页面的复杂性，因此在创建“子页面”时，我需要父页面更新对其子页面的引用。
我想到了一些可能的方法，但感觉不完整。
- 将所有事件发送到单个网页，并在创建页面时查找父页面（如果有）并传达已添加新子页面的信息
- 将所有事件发送到单个WebPage，并在创建页面时将消息发送给父级，然后它将创建一个新的命令来告诉子级进行初始化
- 创建一个作为 WebPageRepository 的基础架构，它将跟踪页面树并将 CRUD 命令中继到所有网页参与者。
我认为，我真正的问题是，在将消息转发给必须实际执行工作的其他参与者时正确处理 Futures 的返回。
我很困惑，非常感谢一些阅读资源。
感谢您的宝贵时间。
编辑：第一个版本是在讨论一个通用的分层文件系统结构。我更新了真正的目的、网页和网址，并试图更好地澄清我的问题
【问题讨论】：
-
首先......这个目录和文件的例子有点尴尬，因为目录和文件是静态资源，对于演员来说并不是一个很好的用例。第二件事是，每个系统设计都是一个高度基于意见和需求的问题。因此，即使您提供了一个更好的示例，我也不确定我们的建议是否会对您的目的有所帮助。
-
嗯，“这对演员来说并不是一个很好的用例”是一个完全可以接受的答案，我已经开始考虑这个问题了。但是，该示例仍然适用，因为真正的用例不是文件和目录，而是网页，所以是的，正如您所指出的，基本上仍然是静态的东西。我仍然会等待其他人的意见，同时回到设计表以另一种可能更经典的方式思考它。谢谢。
-
你开始谈论网页/网址的那一刻......事情发生了很大变化。因为，如果您的演员更像是“用于原子访问这些 url 的客户端”，那么演员模型突然开始变得更有意义。
-
是的，这就是我的意图：演员 == 网页通过其路径在集群中被明确标识（例如 /questions/60037683），我可以在该网页上执行操作，例如编辑它或在其内部发布一个子页面。这就是麻烦开始的时候，当将页面嵌套到其他页面时，并且让整个系统都知道这个嵌套结构已经改变了。
-
@Luca 为什么你需要“让整个系统知道这个嵌套结构已经改变了”？听众不会只对特定的目录更改感兴趣吗？
标签： scala akka event-sourcing akka-cluster