辅助副本在Service Fabric中是必不可少的

时间:2018-07-30 09:10:24

标签: c# azure-service-fabric

我是有状态服务的新手。我需要使用可靠的集合将数据分布在整个群集中。

这很好。

我对二级副本感到困惑。我的系统将数据写入数据库。

通过查看文档,辅助副本也可以保持状态。但是,由于我不希望它们写入数据库,因此它们永远不会真正准确。

那么在我的情况下,实际上是否需要它们?如何使用状态服务仅在群集中对数据进行分区而不必担心副本?我误会了吗?

1 个答案:

答案 0 :(得分:0)

如果您将可靠集合用作主要存储,是的,辅助副本对于保持数据在不同节点之间的复制以及在节点发生故障时保持数据的可用性至关重要。

由于您还将相同的数据添加到数据库中,因此丢失数据的风险不大,但是将副本保留在集群中将是有益的,因为如果一个节点发生数据故障(在主机更新和硬件故障期间非常常见),您将不得不将数据库与新服务实例同步,并且当此数据太大时,同步可能会花费太长时间,因此您的服务将必须等待同步完成在再次使用它之前,如果已经在其他节点上复制了副本,则在发生故障的情况下唯一需要的过程是将辅助节点选为主要节点,并以最小的停机时间继续进行处理。

在我看来,您所做的只是在过程中增加了额外的开销,因为当您必须将数据写回数据库时,将数据保留在节点中所获得的性能会丢失,除非这只是静态数据用于查询。此外,保持同步的复杂性,例如,在将其保存到数据库中并已将其写入Reliable Collection和Vice Versa时,可能会遇到问题,必须处理不同存储上的回滚或使其不同步。

也许您可以考虑将有状态服务替换为无状态服务,并在服务和数据库之间添加一个缓存层,在该调用中,每次获取数据库中项目的调用都会检查该项目是否还不在缓存中,如果不是,从数据库中获取并添加到缓存,以防万一,您可以使用:

  • 如果使用的是.Net,则通过MemoryCache进行InProcess缓存;
  • Azure Redis缓存在群集的同一区域\区域中
  • Redis缓存与GuestExecutable(单独的节点)在同一群集中
  • Redis缓存作为辅助工具,与服务一起部署在同一节点上

您还可以使用无状态服务来定义服务结构的分区概念,其中每个服务将负责一组数据,this documentation的第一部分对此进行了解释。

关于使用Redis的争论:Redis是目前最可靠的缓存解决方案之一,我认为并发对您来说不是问题,它也可以作为GuestExecutble或集群的一部分部署在您的集群中。作为容器(首选)。

除非DB + Cache成为当前状况的瓶颈,否则100000个项目几乎是零,并且任何DB系统都可以很好地处理该问题,因此我建议您仅使用DB解决方案,因为它更加成熟且互联网上的内容涵盖了大多数用例。采用可靠的收集将增加解决方案的复杂性和维护性,在这种规模上不会带来太多好处。