2

我们目前正在构建一个应该能够处理大量传感器事件的系统。

由于需要处理数百万个不同的传感器实例，我认为 Service Fabric Actor 模型将是一个完美的选择。所以想法是让一个 Actor 负责处理一个传感器的事件 (SensorId=ActorId)。

映射很简单，因为我们只需要通过特定的 SensorId 来查询数据，所以我们将所有这些都放在了一个地方，这样可以实现非常快速的查找。

现在的问题是（一些）传感器正在以单个参与者无法处理的速率发送数据。

这就是我们现在被卡住的情况，我们无法提示系统并告诉它为特定传感器（如 Sensor123 和 Sensor567）分配负载到更多 Actor。

是否有可能使用 Service Fabric 提供的虚拟 Actor System 来解决这个问题？

更新 1：

我认为我们对单个演员进行缩放没有问题。我们为一位独特的演员获得大约 5k 条消息/秒。但有些传感器需要 50-100k/s 的目标吞吐量。因此，按照设计（单线程执行），单个参与者将无法完成此操作。

因此，为了澄清最初的问题：我们或多或少地在寻找一种自动划分“某些”参与者的方法。

（当然，我们可以为每个传感器创建 10 个参与者来划分负载。但这会使查找效率低下，另外我们需要 10 倍以上的 RAM。这似乎不合理，因为 0.5-1% 的传感器需要更多吞吐量)

4

2 回答 2

1

我建议调查以下选项：

  1. 向上/向外扩展集群。拥有更多的 CPU 功率会增加吞吐量。每台机器减少 Actors 也会有所帮助。
  2. 使用入口队列，如事件中心，或在 Service Fabric 中创建队列。例如，使用 Actor 将事件排入其 中StateManager，并Reminder在后台处理它们。通过这种方式，事件的处理与接收事件分离。（不过你会变成一个“最终一致性”的模型）
  3. 通过将职责划分为不同的 Actor 类型，使您的 Actor 更小。通过这种方式，您可以更好地在集群中分配负载，但代价是一些延迟。
于 2017-04-24T08:18:01.403 回答
0

我认为它不会提供您所要求的足够收益，但是您是否尝试过为这种“特殊情况”传感器测试一种新的 Actor 类型，该传感器使用一种不太耐用的持久性方法？

比如 StatePersistence.Volatile 还是 StatePersistence.None？我已经看到这显着提高了参与者的吞吐量，尤其是 statePersistnce.None。

显然，这可能不符合您所需的耐用性要求，但在您获得长期解决方案之前，它可能是一个快速的胜利。

必须同意@LoekD，选项 3 将是您最好的选择。尝试将职责细分为不同的参与者，然后它们可以聚合（按循环计划？）并报告给可以处理报告负载的传感器的上帝参与者 - 这再次导致一些最终的一致性，可能会或可能不会可以接受您的用例。

如果一切都失败了，您可以尝试在裸机而不是虚拟机上运行集群，以获得可观的性能增益。

最后一招，在裸机上评估 Erlang……从来没有.NET 开发人员说过

于 2017-04-26T13:52:06.463 回答