用于处理传感器数据的 Service Fabric Actor答案

【问题标题】：Service Fabric Actors for processing Sensor Data用于处理传感器数据的 Service Fabric Actor
【发布时间】：2017-09-20 03:54:25
【问题描述】：

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

由于需要处理数百万个不同的传感器实例，我认为 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% 的传感器需要更高的吞吐量）

【问题讨论】：

【解决方案1】：

我建议调查以下选项：

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

【讨论】：

【解决方案2】：

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

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

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

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

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

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

【讨论】：