Service Fabric 可靠集合答案

【问题标题】：Service fabric reliable collectionsService Fabric 可靠集合
【发布时间】：2017-12-08 20:38:06
【问题描述】：

Service Fabric 可靠集合的理由是什么。我正在与之合作的团队正在用无状态替换有状态服务并将状态删除到 redis 服务器。据我了解，服务结构应该消除不必要的谈话并快速解决问题。我猜是服务结构中的持久性状态参数和调试太难了，以至于团队放弃了它。

我们应该如何处理服务结构项目

我仍然认为 SF 是要走的路，因为它为我们提供了 1000 台服务器虚拟机规模集架构。

【问题讨论】：

这一切都是为了将数据保持在最接近使用它的位置。在有状态服务的情况下，要避免对持久层（无论是 redis、数据库还是其他东西）进行潜在的网络调用。
PS.：它为您提供大规模可能性的事实不应该是使用 ASF 的唯一原因。 Web 应用程序也可以很好地扩展，几乎没有人会需要 1000 台机器的 SF 集群，除非你有一个非常大的解决方案。但是，鉴于您对团队的陈述，您可能想知道他们是否能够胜任这项任务。如果您对使用 ASF 感到不自在，则不应使用它或投资于深入了解它。
我不知道为什么这个问题被降级了。这是一个非常有效的问题。我也有。

【解决方案1】：

如果

如果需要上述所有功能，可靠的集合是一个绝妙的解决方案。单个点可以通过其他方式实现，但将所有点放在一起需要一些繁重的工作和思考/经验。

使所有服务无状态将使单个服务更快，但它们仍然需要读取和写入 redis，这是另一个需要维护和提供高可用性的可执行文件。

【讨论】：

@Ashish，目前可靠的集合被复制到磁盘，但是 Reliable Actors API 支持复制到内存。请参阅文档here。我希望有一天 Reliable Collections 支持与 Reliable Actors 相同的持久性选项。