用于处理传感器数据的Service Fabric Actors

Question

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

由于要求处理数百万个不同的传感器实例，我认为Service Fabric Actor模型非常适合。 所以我的想法是让一个Actor负责处理一个传感器的事件（SensorId = ActorId）。

映射很简单，因为我们只需要通过特定的SensorId查询数据，我们就可以在一个地方进行查询，从而实现快速查找。

现在的问题是（少数）传感器以单个演员无法处理的速率发送数据。

这是我们现在被困住了，我们无法提示系统并告诉它将负载分配给更多Actors，用于特定传感器，如Sensor123和Sensor567。

有没有可能通过Service Fabric提供的虚拟Actor系统来解决这个问题？

更新1 ：

我认为我们在缩放单个演员方面没有问题。我们为一个独特的演员获得大约5k个消息/秒。 但是一些传感器需要50-100k / s的目标吞吐量。因此，通过设计（单线程执行），单个演员无法完成此任务。

所以澄清一下最初的问题：我们或多或少地想要一种自动分区的方法，而有些＆＃34;演员。

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

Answer 1

我建议调查以下选项：

1. 向上/向外扩展群集。拥有更多的CPU功率可以提高吞吐量。每台机器的演员数量减少也会有所帮助。
2. 使用入口队列（如Event Hub）或在Service Fabric中创建队列。例如，使用Actor在其StateManager中排队事件，并使用Reminder在后​​台处理它们。这样，事件的处理与接收它们分离。 （你将改为'最终一致性'的模型）
3. 通过将职责划分为不同的Actor类型，使您的Actors更小。这样，您可以更好地在群集中分配负载，但代价是延迟。

Answer 2

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

如StatePersistence.Volatile还是StatePersistence.None？我已经看到这显着提高了演员的吞吐量，特别是statePersistnce.None。

显然，这可能不符合您所期望的耐久性要求，但在获得长期解决方案之前可能会很快获胜。

必须同意@LoekD，选项3将是您最好的选择。尝试将责任细分为不同的角色，然后可以聚合（按照重复的时间表？）并向该传感器报告可以处理报告负载的神 - 演员 - 这再次导致某些最终的一致性，可能会也可能不会你的用例是可以接受的。

如果所有其他方法都失败了，您可以尝试在裸机而不是虚拟机上运行群集，以获得相当大的性能提升。

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