我有一个场景，我们需要存储 x*100 GB 的数据。一般来说，数据是服务结构集群本身中参与者（良好分区，仅由特定参与者使用）持久状态的良好候选者。
对于这种规模的数据，是否建议使用服务结构持久状态存储？ （我们的计算负载将相当低，因此仅仅为了存储状态而增加虚拟机并不是一个理想的选择。）
持久状态的数量如何影响集群中节点之间移动分区的延迟？
好吧，让我们看看状态是如何存储在服务中的（这也适用于参与者）。
在服务中存储数据的组件称为状态提供者。状态提供程序可以仅位于内存中，也可以位于内存+本地磁盘中。通过 Actor 服务获得的默认状态提供程序是内存中 + 本地磁盘，但它仅将热数据保留在内存中，因此您的存储要求不受内存限制。与目前将所有数据存储在内存中和本地磁盘上的 Reliable Collections 状态提供程序相比，尽管在未来版本中它也可以选择仅将热数据保留在内存中并将其余数据卸载到本地磁盘。
鉴于您正在使用参与者，您可以使用默认的参与者状态提供程序，这意味着您的数据容量受到计算机或虚拟机上的本地磁盘存储的限制，这对于存储 100 GB 来说应该是合理的。我们通常不会移动整个分区，但有时 Service Fabric 确实需要重建服务的副本，并且拥有的数据越多，构建副本所需的时间就越长。但是，这并不会真正影响服务的延迟，因为有状态服务中有多个副本，并且通常有足够的副本，无需等待另一个副本重建。重建副本通常是“偶然”发生的事情。
确实，仅仅为了存储状态而添加虚拟机并不经济，但请记住，您可以根据需要将任意数量的服务打包到虚拟机上。因此，即使您的 Actor 服务没有使用太多计算，您也始终可以在这些虚拟机上打包其他服务以使用该计算，以便最大限度地利用虚拟机上的计算和存储，这实际上非常经济。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
