Service Fabric 中的 actorevent 都有哪些限制？

Posted 2023-03-27

【中文标题】Service Fabric 中的 actorevent 都有哪些限制？

【英文标题】：What are the limits on actorevents in service fabric?Service Fabric 中的 actorevent 有哪些限制？

【发布时间】：2021-05-28 15:11:03

【问题描述】：

我目前正在测试我的应用程序的扩展性，但遇到了一些我没有预料到的事情。

应用程序在 5 节点集群上运行，它具有多个服务/参与者类型，并且使用共享进程模型。 对于某些组件，它使用 actor 事件作为尽力而为的 pubsub 系统（存在回退，因此如果删除通知，则没有问题）。 当参与者的数量增加（也称为订阅主题）时，就会出现问题。 actorservice 目前被划分为 100 个分区。 此时的主题数量约为 160.000，其中每个主题被订阅 1-5 次（需要它的节点），平均订阅 2.5 次（大约 40 万订阅）。

此时集群中的通信开始中断，未创建新订阅，取消订阅超时。 但它也会影响其他服务，对诊断服务的内部调用超时（询问 5 个副本中的每一个），这可能是由于分区/副本端点的解析，因为对网页的外部调用很好（这些端点使用相同的技术/代码栈）。

事件查看器充满警告和错误，例如：

EventName: ReplicatorFaulted Category: Health EventInstanceId c4b35124-4997-4de2-9e58-2359665f2fe7 PartitionId a8b49c25-8a5f-442e-8284-9ebccc7be746 ReplicaId 132580461505725813 FaultType: Transient, Reason: Cancelling update epoch on secondary while waiting for dispatch queues to drain will result in an invalid state, ErrorCode: -2147017731
10.3.0.9:20034-10.3.0.13:62297 send failed at state Connected: 0x80072745
Error While Receiving Connect Reply : CannotConnect , Message : 4ba737e2-4733-4af9-82ab-73f2afd2793b:382722511 from Service 15a5fb45-3ed0-4aba-a54f-212587823cde-132580461224314284-8c2b070b-dbb7-4b78-9698-96e4f7fdcbfc

我已尝试扩展应用程序，但没有激活此订阅模型，我很容易达到两倍大的工作负载而没有任何问题。

所以有几个问题

actor 事件是否存在已知限制/建议限制？ 增加分区数或/和节点数会有所帮助吗？ 通信干扰是否合乎逻辑？为什么其他服务端点也有问题？

【问题讨论】：

正如本周早些时候 44:17 在youtube.com/watch?v=oX9cX69mk5o 上所传达的那样，演员活动没有硬性限制，但我推断您可能有运气提交支持票以挖掘实际资源使用集群来确定问题的根源。

谢谢，我最终向马特提供了更多信息，之后他让我开一张支持票。当我知道更多时，我会更新/回答这个问题

@P.Gramberg 你有没有找到更多关于这个的信息？

@Oliver 我的工单仍在由微软处理，我们发现线程数对于空闲系统（200-300 个线程）来说是疯狂的。他们有一个复制案例，所以工程师现在正在研究它。由于整个大流行情况，一切都需要更长的时间。当我知道更多时，我会回来报告

【参考方案1】：

花时间处理支持票后，我们发现了一些信息。所以我会在这里发布我的发现，以防它对某人有所帮助。

参与者事件使用重新订阅模型来确保它们仍然与参与者相关联。默认每 20 秒执行一次。这意味着正在使用大量资源，最终整个系统因等待重新订阅的空闲线程负载而过载。 您可以通过在订阅时将resubscriptionInterval 设置为更高的值来减少负载。缺点是这也意味着客户端可能会同时错过事件（如果移动分区）。

为了抵消重新订阅的延迟，可以挂钩到较低级别的服务结构事件。在支持电话中向我提供了以下伪代码。

注册参与者服务的端点更改通知

           fabricClient.ServiceManager.ServiceNotificationFilterMatched += (o, e) =>
            
                var notification = ((FabricClient.ServiceManagementClient.ServiceNotificationEventArgs)e).Notification;
                /*
                 * Add additional logic for optimizations
                 * - check if the endpoint is not empty
                 * - If multiple listeners are registered, check if the endpoint change notification is for the desired endpoint
                 * Please note, all the endpoints are sent in the notification. User code should have the logic to cache the endpoint seen during susbcription call and compare with the newer one
                 */
                List<long> keys;
                if (resubscriptions.TryGetValue(notification.PartitionId, out keys))
                
                    foreach (var key in keys)
                    
                        // 1. Unsubscribe the previous subscription by calling ActorProxy.UnsubscribeAsync()
                        // 2. Resubscribe by calling ActorProxy.SubscribeAsync()
                    
                
            ;

            await fabricClient.ServiceManager.RegisterServiceNotificationFilterAsync(new ServiceNotificationFilterDescription(new Uri("<service name>"), true, true));

将重新订阅间隔更改为适合您需要的值。 缓存分区 id 到 actor id 的映射。当副本的主端点更改时，此缓存将用于重新订阅（参考 #1）

              await actor.SubscribeAsync(handler, TimeSpan.FromHours(2) /*Tune the value according to the need*/);
              ResolvedServicePartition rsp;
              ((ActorProxy)actor).ActorServicePartitionClientV2.TryGetLastResolvedServicePartition(out rsp);
              var keys = resubscriptions.GetOrAdd(rsp.Info.Id, key => new List<long>());
       keys.Add(communicationId);

上述方法确保以下

订阅会定期重新订阅 如果主端点在两者之间发生变化，actorproxy 会从服务通知回调中重新订阅

这将结束来自支持调用的伪代码。

回答我最初的问题：

演员事件是否存在已知限制/建议限制？

没有硬性限制，只有资源使用。

增加分区数或/和节点数有帮助吗？

分区数没有。节点计数可能是，只有当这意味着节点上的订阅实体因此而减少时。

通信干扰是否合乎逻辑？为什么其他服务端点也有问题？

是的，资源争用是原因。