Akka如何实现横向扩展？
How to achieve horizontal scalability in Akka?
在 Principles of Reactive Programming course 中，Roland Kuhn 在可扩展性 class 中解释说
Asynchronous message passing enables vertical scalability
Location transparency enables horizontal scalability
据我了解，位置透明性只能为无状态参与者启用水平可扩展性，但对于有状态参与者，我们需要 Cluster sharding
Cluster sharding is typically used when you have many stateful actors
that together consume more resources (e.g. memory) than fit on one
machine
例如，我想象一个在线零售商的 DDD 方法，我有一个 ShoppingCartAggregate。在峰值负载期间，我将需要创建数千个 ShoppingCartAggregate 参与者，应用程序可能会变得无响应。
在这种情况下，实现水平可扩展性的方法是通过集群分片并将参与者重新平衡到另一个节点吗？
罗兰回答后更新：
我知道位置透明性是集群分片的必要条件，但据我所知（实际上还没有）位置透明性不足以水平扩展有状态的参与者。
经过你的许可，我想粘贴一张幻灯片（如果你想让我删除它，请告诉我）：
我将此示例更多地视为容错的情况，而不是水平可伸缩性的情况，因为我们在另一个节点 B 中复制了参与者 A，并且当节点 A 出现故障时它开始处理消息。
如果节点 A 中的参与者 A 接收到意外负载，消息将开始排队并且需要更多时间来回复，我看不出有什么办法可以防止这种情况发生。然而，在 DDD 方法中，由于参与者的粒度，这不太可能发生：所有客户端都不会向同一实体发送消息。
但是如果我有 10000 个代表不同实体的 actor 生活在节点 A 中，并且它们都收到了意外负载，我们可以使用集群分片来重新平衡节点 A 和 B 之间的 10000 个 actor，实现水平可扩展性。
我正在学习分布式系统和 akka，所以我正在尝试加入这些点，这只是一个问题，我没有做任何形式的肯定。
更新：
又看了一遍视频讲座，我怎么没看懂你说的有状态actors的复制：
Here, replication is not used for scalability so much, but it can also be used for fault tolerance.
集群分片的工作原理是利用 Akka 的 Actor 模型实现所提供的位置透明性。这里的要点是，只有当客户端（即与 ShoppingCartAggregate 对话的代码）不需要知道或关心每个特定实例所在的位置时，才能实现水平可伸缩性——ShardRegion 可以将请求路由到正确的目的地透明时尚。当考虑在运行时进行动态重新平衡时，这一点变得更加重要，这意味着参与者在集群中移动，而他们的任何客户都不知道差异。
因此，这个问题的简短回答是您提出了错误的二分法。
在 Principles of Reactive Programming course 中，Roland Kuhn 在可扩展性 class 中解释说
Asynchronous message passing enables vertical scalability
Location transparency enables horizontal scalability
据我了解，位置透明性只能为无状态参与者启用水平可扩展性，但对于有状态参与者，我们需要 Cluster sharding
Cluster sharding is typically used when you have many stateful actors that together consume more resources (e.g. memory) than fit on one machine
例如，我想象一个在线零售商的 DDD 方法，我有一个 ShoppingCartAggregate。在峰值负载期间，我将需要创建数千个 ShoppingCartAggregate 参与者，应用程序可能会变得无响应。
在这种情况下，实现水平可扩展性的方法是通过集群分片并将参与者重新平衡到另一个节点吗？
罗兰回答后更新：
我知道位置透明性是集群分片的必要条件，但据我所知（实际上还没有）位置透明性不足以水平扩展有状态的参与者。
经过你的许可，我想粘贴一张幻灯片（如果你想让我删除它，请告诉我）：
我将此示例更多地视为容错的情况，而不是水平可伸缩性的情况，因为我们在另一个节点 B 中复制了参与者 A，并且当节点 A 出现故障时它开始处理消息。
如果节点 A 中的参与者 A 接收到意外负载，消息将开始排队并且需要更多时间来回复，我看不出有什么办法可以防止这种情况发生。然而，在 DDD 方法中，由于参与者的粒度，这不太可能发生：所有客户端都不会向同一实体发送消息。
但是如果我有 10000 个代表不同实体的 actor 生活在节点 A 中，并且它们都收到了意外负载，我们可以使用集群分片来重新平衡节点 A 和 B 之间的 10000 个 actor，实现水平可扩展性。
我正在学习分布式系统和 akka，所以我正在尝试加入这些点，这只是一个问题，我没有做任何形式的肯定。
更新：
又看了一遍视频讲座，我怎么没看懂你说的有状态actors的复制：
Here, replication is not used for scalability so much, but it can also be used for fault tolerance.
集群分片的工作原理是利用 Akka 的 Actor 模型实现所提供的位置透明性。这里的要点是，只有当客户端（即与 ShoppingCartAggregate 对话的代码）不需要知道或关心每个特定实例所在的位置时，才能实现水平可伸缩性——ShardRegion 可以将请求路由到正确的目的地透明时尚。当考虑在运行时进行动态重新平衡时，这一点变得更加重要，这意味着参与者在集群中移动，而他们的任何客户都不知道差异。
因此，这个问题的简短回答是您提出了错误的二分法。