问题描述
我有一个有关集群分片和'state-store-mode = ddata'....
的问题。我们有一个拥有1亿个Actor的Actor系统，并且我们正在使用Cluster Sharding，开箱即用，它被配置为“分布式数据” ddata，而在Cluster Sharding页面中，它用大写字母写在这里{ {3}}
Warning
Persistence for state store mode is deprecated. It is recommended to migrate to ddata for the coordinator state and if using replicated entities migrate to eventsourced for the replicated entities state.
The data written by the deprecated persistence state store mode for remembered entities can be read by the new remember entities eventsourced mode.
Once you’ve migrated you can not go back to persistence mode.
但是我还在互联网上发现一些文章，指出akka分布式数据对于大型系统而言并不是一个好主意，因此我认为可以将1000万参与者定义为大型系统...。
Akka Distributed Data - Scaling
所以我的问题是
- 您知道哪些配置参数会影响clsuter分片-分布式数据的缩放
- 对于集群分片，我的实验表明，当我拥有更多分片时，分片分布式数据可以更好地扩展。这是正确的假设吗？
- 如果该Actor编号不适合分布式数据，我应该坚持“持久性”模式，在Akka文档中将其标记为已弃用....
- 如果无法使用ddata和持久性来处理如此大量的actor，应该使用....
寻求答案
解决方法
您知道哪些配置参数对 分片的比例缩放-分布式数据
分布式数据对分片的缩放没有任何直接影响。它最多可以处理100000个实体，从而可以支持多达10s of thousands shards个。
从客户端到分片分配策略的通信是 通过分布式数据。它使用单个LWWMap，可以支持10s 成千上万的碎片。更高版本可以使用多个键来支持 更多的分片。
您可以使用以下参数控制分片的数量
akka.cluster.sharding {
# Number of shards used by the default HashCodeMessageExtractor
# when no other message extractor is defined. This value must be
# the same for all nodes in the cluster and that is verified by
# configuration check when joining. Changing the value requires
# stopping all nodes in the cluster.
number-of-shards = 1000
}
它将按照rule
创建指定数量的分片默认情况下，分片标识符是hashCode的绝对值 实体标识符以分片总数为模。
对于集群分片，我的实验表明，当我有更多分片时， 分片分布式数据可更好地扩展。这是正确的假设吗？
是，不是。分片太少会带来实体分配不均的问题，分片太多会给分片分配带来问题。分片的黄金数量是节点数乘以10。请参见相同的docs。
根据经验，分片的数量应为系数十 大于计划的最大群集节点数。没有 必须准确。分片少于节点数将导致 某些节点将不会托管任何分片。碎片太多 分片的管理效率较低，例如重新平衡开销， 并增加了延迟，因为协调员参与了 每个分片的第一条消息的路由。
如果“分布式数据”不适用于此演员编号，则应 我坚持使用“持久性”模式，在Akka文档中将其标记为 不推荐使用......
一千万个参与者不会影响分片状态的大小，因此使用ddata模式是合适的。