我有一个场景，我们需要存储x * 100 GB的数据。在服务结构集群本身中，数据通常是演员（持久分区，仅由特定演员使用）的持久状态的良好候选者。
对于此规模的数据，是否建议使用服务结构持久状态存储？ （我们的计算负载相当低，因此仅仅为了存储状态而增加虚拟机并不是一个理想的选择。）
持久状态量如何影响群集中节点之间移动分区的延迟？
答案 0 :(得分：8)
让我们看看状态如何存储在服务中（这也适用于演员）。
将数据存储在服务中的组件称为State Provider。状态提供程序可以是仅内存或本地内存+本地磁盘。使用actor服务获得的默认状态提供程序是内存+本地磁盘，但它只将热数据保存在内存中，因此您的存储要求不受内存限制。与Reliable Collections状态提供程序进行对比，该状态提供程序当前存储内存和本地磁盘上的所有数据，但在将来的版本中，它还可以选择仅将热数据保留在内存中，并将其余数据卸载到本地磁盘。
鉴于您正在使用actor，您可以使用默认的actor状态提供程序，这意味着您的数据容量受到计算机或VM上的本地磁盘存储的限制，这对于存储100 GB是合理的。我们通常不会移动整个分区，但偶尔Service Fabric确实需要重建您的服务副本，并且您拥有的数据越多，构建副本所需的时间就越长。但是，这并不会真正影响您的服务延迟，因为您在有状态服务中拥有多个副本，并且您通常拥有足够的副本，而您不需要等待另一个重建。重建副本通常是发生在一边的事情。＆＃34;
确实，仅仅为了存储状态添加虚拟机是不经济的，但请记住，您可以根据需要将尽可能多的服务打包到虚拟机上。因此，即使您的actor服务没有使用大量计算，您也可以始终在这些VM上打包其他服务以使用该计算，以便最大化VM上的计算和存储，这实际上可能是非常经济。