问题标签 [service-fabric-stateful]

这可能是一个非常微不足道的问题，但只是想问（在完成我的初步搜索之后）。持久性 SF 演员在 60 分钟（默认）空闲（未使用）后收集垃圾。ReceiveReminderAsync如果我创建了超过 60 分钟的提醒，仍然会被调用吗？

当服务向命名服务注册自己时，似乎用作键的服务名称 (/) 在内部字典中是区分大小写的。

此设计决策/错误的副作用是解决服务的调用者必须提供准确的区分大小写的 url (fabfic://.

更大的影响是使用反向代理，因为如果最终调用者（集群外的调用者）没有将正确的大小写放在以下反向代理语义路径中

那么服务没有得到解决。所以从某种意义上说，现在取决于调用者是否得到解决，我们现在说我们的产品 url 区分大小写。

问题

a) 这是 SF 团队深思熟虑的决定还是一个错误？

b) 是否有任何指导方针。我可以用自定义代码替换反向代理，而不是规范我们为集群同意的大小写模式。

谢谢

我需要在 Service Fabric 上的 Reliable Dictionaries 中存储大量数据。我们将事件存储实现为多个可靠字典，因此域发出的每个事件最终都在存储中。我想知道以下两种情况下的性能差异：

• 使用一个（非常大的）可靠字典来存储某种聚合类型的所有事件：这会产生少量的字典，每个字典都包含数百万个事件
• 使用一个小的 Reliable Dictionary 来存储单个聚合实例的事件：这会产生很多小字典（想想数百万），每个字典都包含一些事件

鉴于状态的复制和读写性能，最有效的前进方式是什么？

What is the justifications for the service fabric reliable collections. The team I am working with is replacing the stateful services with stateless and removing the state to a redis server. As far as I understood was service fabric should eliminate the unnecassary talk and be fast at solving issues. I guess the persistance state parameter in service fabric and the debugging is so hard that the team gave up on it.

How should we approach service fabric projects

PS

I still feel that SF is the way to go as It gives us the 1000 server Virtual Machine scale sets architecture.

在试验 Service Fabric 远程处理时，我有一些未正确序列化的数据类型。这给我带来了很多问题。

从文档看来，一切都需要用 [DataContract] 装饰。在某些测试类型上使用它之后，它们确实可以正确序列化。

但是坦率地说，我不想装饰所有东西。这对我来说将是一个巨大的倒退。我宁愿一直使用自定义序列化。

该文档似乎表明可以注册自定义序列化程序，但它似乎仅适用于有状态服务。我主要使用远程处理和无状态服务。

我正在本地设置一个服务结构集群并定义了一个可靠的参与者。我已将应用程序发布到集群。

我在公开端点以便客户端可以使用时遇到困难。我尝试在 ServiceManifest 中添加端点并在本地部署集群。但是在添加端点的那一刻，集群无法部署。

注意：我正在使用 Service Fabric 的 Actor Service 模板并添加了 Reliable Actor。

谢谢！

我正在使用 Service Fabric 有状态服务来存储有关系统中用户的状态。我的分区策略是使用标准化的国际字符串格式电话号码来寻址命名服务实例，并使用电话号码的哈希来解析该服务的分区。例如：fabric:/myapp/users/1/718（国际电话号码是 +1718xxxxxxx）这使我可以根据他们的国家（以及美国/加拿大市场的区号）对服务进行地理定位。

我的问题是理论上的，但在本质上也是实用的。 谁拥有服务解析的逻辑？ 一个简单的方法是只要求任何依赖此服务的人都知道它是如何分区的，但这对我来说感觉像是一个泄漏的抽象。此外，我想为用户分配一个与电话号码概念分离的 ID。

1. 我最初的方法是使 Id 成为一个字节 []，其中包括用户的服务名称、分区 id 和本地 id。我放弃了这个想法，因为 ID 的大小非常大，并且会随着时间的推移而增加。（这是有问题的，因为 Reliable Dictionary 中的所有键都需要放入内存中，我不想在 id 上杀死大量内存）此外，它仍然带有每个使用 id 知道如何解释 id 的包袱并相应地使用它。
2. 我的下一个想法是为使用该服务的任何人提供客户端库。这也有消费服务的二进制依赖的缺点。如果我想在未来改变策略，我必须跳过一堆箍来处理失败以正确解决实体。
3. 我能想到的最后一个选择是在有状态服务之前有一个无状态代理来处理所有服务的解析。从设计的角度来看，这是最吸引人的，但也涉及管理、构建另一个服务，只是为了解决问题。不反对它，但它是一个额外的考虑。如果我走这条路，我应该将此服务作为一个单独的服务结构应用程序，还是建议将所有内容都保留为一个应用程序。

我也愿意接受以这种方式划分用户是一个坏主意的想法。但是，出于多种原因，建议使用手机。

我试图理解为什么我们的演员服务使用的磁盘空间比预期的要多。我们的服务目前包含分布在 10 个分区上的大约 80,000 个演员。每个参与者存储大约 150Kb 的状态。

查看集群中的一个（共 10 个）节点，我希望看到：

• 用于大约 3 个分区的磁盘空间（一个作为主分区，两个作为辅助分区）
  • 这和预期的一样
• 深入到一个分区文件夹，我希望只看到一个副本 ID
  • 不像预期的那样：
    • 我看到了预期的一个（与 Service Fabric Explorer 中节点部分下列出的副本匹配的那个）。副本 id 以R_
    • 在同一个分区文件夹中，我看到其他 3 个副本 ID 以前缀开头的文件夹S_。这些副本 ID 与“应用程序”节点下的 Service Fabric Explorer 中列出的任何值都不匹配。
• 查看以 R_ 开头的副本文件夹，我希望该文件夹包含的大小不会超过 8000 个演员的大小，每个演员占用大约 150 Kb，即大约 1.14 Gb 的数据。
  • 不像预期的那样：
    • 该文件夹包含一个文件ActorStateStore，其大小为 5.66Gb

我想了解的另一件事是：

• 我们的应用程序的版本 1 没有清理未使用的演员。正如您所料，我们看到每个节点上的磁盘使用率都在稳步增长。
• 我们的应用程序的第 2 版开始删除未使用的演员。由于这个新代码将超过一半的活动参与者，我在部署后的预期是总体使用的磁盘大小会显着下降。
  • 没有发生，增长停止但使用量没有减少。

所以我的问题是：

1. 我的预期正确吗？
2. 什么可以解释我的观察？

我正在为我的有状态服务使用统一的分区方案，并且我成功地在 Azure Blob 存储中备份和恢复状态。该过程依赖于 partitionId 来识别存储特定分区备份的容器。

假设集群始终处于活动状态并且 partitionIds 从未更改，则上述方法非常有效。尽管如此，即使整个集群出现故障，我也一直在思考如何能够恢复我的状态（这反过来又会导致重新创建的集群中的 partitionIds 完全不同）

任何想法......任何人:)？

提前致谢！

如果调用服务结构中的有状态参与者并且参与者未能完成该方法（例如，运行它的机器重新启动/崩溃），该方法是否会在提升为主要的副本之一上恢复（或重新启动） ?