服务结构中的actorevents有什么限制？

Question

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

该应用程序在一个 5 节点集群上运行，它有多个服务/actortypes 并使用共享进程模型。对于某些组件，它使用 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

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

所以有几个问题

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

Answer 1

经过一段时间的支持票后，我们发现了一些信息。因此，我将在这里发布我的发现，以防它对某人有所帮助。

\n

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

\n

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

\n

\n
1. 注册参与者服务的端点更改通知
\n

\n

           fabricClient.ServiceManager.ServiceNotificationFilterMatched += (o, e) =>\n            {\n                var notification = ((FabricClient.ServiceManagementClient.ServiceNotificationEventArgs)e).Notification;\n                /*\n                 * Add additional logic for optimizations\n                 * - check if the endpoint is not empty\n                 * - If multiple listeners are registered, check if the endpoint change notification is for the desired endpoint\n                 * 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\n                 */\n                List<long> keys;\n                if (resubscriptions.TryGetValue(notification.PartitionId, out keys))\n                {\n                    foreach (var key in keys)\n                    {\n                        // 1. Unsubscribe the previous subscription by calling ActorProxy.UnsubscribeAsync()\n                        // 2. Resubscribe by calling ActorProxy.SubscribeAsync()\n                    }\n                }\n            };\n\n            await fabricClient.ServiceManager.RegisterServiceNotificationFilterAsync(new ServiceNotificationFilterDescription(new Uri("<service name>"), true, true));\n

\n

\n
2. 将重新订阅间隔更改为适合您需要的值。\n缓存分区 ID 到参与者 ID 的映射。当副本\xe2\x80\x99s 主端点更改时，此缓存将用于重新订阅（参考＃1）
\n

\n

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

\n

上述方法确保了以下内容

\n

\n
• 订阅会定期重新订阅
\n
• 如果主端点在这期间发生变化，actorproxy 会重新订阅服务通知回调
\n

\n

支持电话中的伪代码就此结束。

\n

回答我原来的问题：

\n

\n
• 演员活动是否有已知/建议的限制？\n没有硬性限制，只有资源使用。
\n
• 增加分区数量或/和节点数量会有帮助吗？分区计数没有。可能是节点数，只有当这意味着节点上的订阅实体因此而减少时。
\n
• 通讯干扰符合逻辑吗？为什么其他服务端点也有问题？\n是的，资源争用就是原因。
\n

\n