我有一个场景，我们需要存储 x*100 GB 的数据。数据通常是服务结构集群本身中参与者（分区良好，仅由特定参与者使用）的持久状态的良好候选者。
对于这种规模的数据，是否建议使用 Service Fabric 持久状态存储？ （我们的计算负载将相当低，因此仅仅为了存储状态而增加虚拟机并不是一个理想的选择。）
持久状态的数量如何影响集群中节点之间移动分区的延迟？
【问题讨论】：
标签： azure azure-service-fabric
让我们看看状态是如何存储在服务中的（这也适用于演员）。
在服务中存储数据的组件称为状态提供程序。状态提供者可以仅在内存中，也可以在内存+本地磁盘中。您使用 Actor 服务获得的默认状态提供程序是内存中 + 本地磁盘，但它仅将热数据保存在内存中，因此您的存储需求不受内存限制。与 Reliable Collections 状态提供程序相反，后者当前将所有数据都存储在内存中和本地磁盘上，尽管在未来的版本中，它还可以选择仅将热数据保留在内存中并将其余数据卸载到本地磁盘。
鉴于您正在使用 Actor，您可以使用默认的 Actor 状态提供程序，这意味着您的数据容量受到机器或 VM 上本地磁盘存储的限制，这对于存储 100 GB 应该是合理的。我们通常不会移动整个分区，但有时 Service Fabric 确实需要重建服务的副本，并且您拥有的数据越多，构建副本所需的时间就越长。但是，这并不会真正影响您的服务的延迟，因为您在有状态服务中有多个副本，并且您通常有足够的副本，您不需要等待重建另一个副本。重建复制品通常是“偏偏”的事情。
确实，添加虚拟机只是为了存储状态并不经济，但请记住，您可以根据需要将任意数量的服务打包到虚拟机上。因此，即使您的参与者服务没有使用太多计算，您也可以随时在这些 VM 上打包其他服务以使用该计算，这样您就可以最大限度地利用 VM 上的计算和存储，这实际上是非常经济的。
【讨论】：