Azure Service Fabric 如何调整 Actor 和网络的大小答案

【问题标题】：Azure Service Fabric how to size Actors and networksAzure Service Fabric 如何调整 Actor 和网络的大小
【发布时间】：2016-11-07 16:42:54
【问题描述】：

应该应用哪些方法来确定 Azure Service Fabric 有状态 Actor 系统的正确 Actor 大小？

走极端，我可以理论上只有 1 个具有 所有状态 的演员，反之则使用一个演员来存储 1 个字符串。显然，这两个都是错误的。

对于单个参与者，如果测量数据的序列化大小，多少 kilo 字节将被视为小，多少 mega 字节将被视为大？例如，10KB 小，10MB 大？

从上述答案构建，假设演员网络受到“小”演员的影响。什么构成小型网络与大型网络？再比如，100 万小，10 亿大？

我强烈希望将某种引用应用于这些测量。但是，我无法从 Azure 文档中获取任何特定内容。如果尚未发布具体信息，我会接受处理与 ASF 不同的参与者网络实现的来源。

【问题讨论】：

在这种情况下，“正确尺寸”是什么意思？演员的实际大小（以千字节为单位）？
@cassandrad 对于单个演员 For example, is 10KB small and 10MB large? 和对于整个网络 For example again, is 1 million small and 1 billion large?
看起来你在询问关于存储在演员中的数据量的“最佳实践”，并且给出一些特定的答案非常广泛。为什么你不能衡量在你的环境中存储不同数量数据的许多参与者的使用情况？

标签： azure actor partitioning azure-service-fabric

【解决方案1】：

一般来说，参与者状态的原始大小不如其范围和访问模式有趣。如果你使用你的actor作为其他组件需要访问的大量状态的“管理者”，你很可能会被actor模型的单线程特性绊倒，因为多个调用者尝试并行提出请求。另一方面，如果您有一个自然封装的 Actor 需要利用大量状态来执行其任务，那么将所有这些状态存储在本地而不是发出一组网络请求可能是有益的。

如果您正在寻找一个非常粗略的经验法则，我希望大多数演员状态都以千字节为单位。如果您超过了兆字节阈值，则值得重新检查您的设计并确保您的演员没有扮演经理或小型数据库角色，使用可靠的服务/可靠的字典会更好。

【讨论】：

您肯定了我对序列化数据大小的假设，即千字节（持久）是最佳点。系统中的参与者数量如何？也许假设每个参与者 5KB 到 25KB（相当连续的数据块，将在单个事务边界中更新）
Actor 服务是分区的，因此它们的数量没有这样的最佳位置。如果您的参与者数量超出硬件限制，您只需向集群添加更多机器，Service Fabric 就会重新平衡。
让我换个说法，您如何处理容量规划，也就是可以应用哪些指标来表示“此时我们应该期望增加服务器”（将它们增加到标准三元组服务器之上）。与反动相反，集群过载/容量不足，我们现在必须立即升级。我总是试图计划消除现在现在的反应。
没有大量的平台状态开销，因此容量规划练习基本上是：自定义参与者状态大小 * 参与者数量 * 副本数。你可以看一个例子here。