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

Question

我是有状态服务的新手。我需要使用可靠的集合在我的集群中传播我的数据。

这很好。

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

查看文档，辅助副本也旨在保存状态。但是，它们永远不会真正准确，因为我不希望它们写入数据库。

那么在我的情况下真的需要它们吗？如何使用有状态服务仅在集群中对数据进行分区而不用担心副本？我是不是误会了什么？

Answer 1

如果您使用 Reliable Collections 作为主存储，是的，辅助副本对于保持您的数据在不同节点之间复制并在节点发生故障时保持数据可用性至关重要。

因为您还将相同的数据添加到数据库中，所以您不会面临丢失数据的风险，但将副本保留在集群中会有所帮助，因为以防一个节点因您的数据而出现故障（这在主机更新和硬件故障期间很常见），您必须将数据库与新服务实例同步，并且当此数据太大时同步可能需要很长时间，因此您的服务将不得不等待同步完成在您再次开始使用它之前，如果您已经在其他节点上复制了副本，则发生故障时唯一需要的过程是选择一个辅助节点作为主节点，并以尽可能短的停机时间继续处理。

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

也许您可以考虑将有状态服务替换为无状态服务，并在您的服务和数据库之间添加一个缓存层，在每次调用获取数据库中的项目时，您都会检查它是否尚未在缓存中，如果没有，从数据库中获取并添加到缓存中，以供您使用：

• 如果您使用的是 .Net，则通过 MemoryCache 进行进程内缓存；
• Azure Redis 缓存在集群的同一区域\专区中
• Redis 缓存在与 GuestExecutable 相同的集群中（单独的节点）
• Redis 缓存作为 sidecar，与您的服务一起部署在同一节点上

您还可以使用无状态服务的服务结构的分区概念，其中每个服务将负责一组数据，this documentation 的第一部分解释了这一点。

关于您的论点，关于使用 Redis：Redis 是目前最可靠的缓存解决方案之一，我认为并发性对您来说不是问题，它也可以作为 GuestExecutble 或作为集群的一部分部署作为容器（首选）。

除非 DB+Cache 成为你当前情况的瓶颈，否则 100000 项几乎没有，任何 DB 系统都可以很好地处理，我建议你只坚持 DB 解决方案，因为它更成熟和互联网上充斥着涵盖大多数用例的内容。采用 Reliable Collections 会增加解决方案的复杂性和维护性，在这种规模上不会带来太多好处。