Акторы Service Fabric для обработки данных датчиков

В настоящее время мы разрабатываем систему, которая должна быть способна обрабатывать большое количество сенсорных событий.

Поскольку требуется обрабатывать миллионы различных экземпляров датчиков, я подумал, что модель Service Fabric Actor Model идеально подойдет. Итак, идея заключалась в том, чтобы иметь одного Актера, который отвечал бы за обработку событий одного датчика (SensorId = ActorId).

Сопоставление простое, и, поскольку нам нужно запрашивать данные только по определенному SensorId, у нас есть все в одном месте, что обеспечивает действительно быстрый поиск.

Проблема в том, что (несколько) датчиков отправляют данные со скоростью, с которой один субъект больше не может справиться.

Это то место, где мы сейчас застряли, мы не можем намекнуть системе и сказать ей, чтобы она распределяла нагрузку на большее количество Актеров для определенных датчиков, таких как Sensor123 и Sensor567.

Есть ли возможность решить эту проблему с помощью виртуальной системы акторов, предоставляемой Service Fabric?

Обновление 1:

Думаю, у нас нет проблем с масштабированием одного актера. Мы получаем около 5 тыс. Сообщений / с для одного уникального актера. Но некоторым датчикам нужна целевая пропускная способность 50–100 тыс. / С. Таким образом, по замыслу (однопоточное исполнение) ни один актер не сможет этого добиться.

Итак, чтобы прояснить исходный вопрос: мы более или менее ищем способ автоматического разделения «некоторых» актеров.

(Конечно, мы могли бы создать 10 актеров для каждого датчика, чтобы разделить нагрузку. Но это сделало бы поиск неэффективным, и, кроме того, нам нужно было бы в 10 раз больше оперативной памяти. Это не кажется оправданным, потому что 0,5–1% датчиков нуждаются в большей пропускной способности. )


person coalmee    schedule 23.04.2017    source источник


Ответы (2)


Я рекомендую изучить следующие варианты:

  1. Увеличьте / уменьшите масштаб кластера. Увеличение мощности процессора увеличивает пропускную способность. Также поможет меньшее количество Актеров на машину.
  2. Используйте входящую очередь, например концентратор событий, или создайте очередь внутри Service Fabric. Например, используйте Актера, чтобы поставить событие в очередь в его StateManager, и Reminder, чтобы обработать их в фоновом режиме. Таким образом обработка событий не связана с их получением. (хотя вы превратитесь в модель «возможной согласованности»)
  3. Уменьшите количество своих актеров, разделив обязанности на разные типы актеров. Таким образом вы лучше распределяете нагрузку по кластеру за счет некоторой задержки.
person LoekD    schedule 24.04.2017
comment
Большое спасибо за вклад! Но в нашем случае эти варианты мало помогут; (. Я обновил свой первоначальный вопрос, чтобы прояснить наши потребности. - person coalmee; 24.04.2017

Я не думаю, что это даст достаточный выигрыш, о котором вы просите, но пробовали ли вы протестировать новый тип актера для этого датчика «особого случая», который использует менее надежный метод сохранения?

Например, StatePersistence.Volatile или StatePersistence.None? Я заметил, что это значительно повысило пропускную способность акторов, особенно statePersistnce.None.

Очевидно, это может не соответствовать вашим желаемым требованиям к долговечности, но может быть быстрой победой, пока вы не получите более долгосрочное решение.

Придется согласиться с @LoekD, вариант 3 будет лучшим выбором. Попытайтесь разделить обязанности на разных участников, которые затем могут объединяться (по повторяющемуся графику?) И отчитываться перед божественным субъектом для этого датчика, который может обрабатывать отчетную нагрузку - опять же, это приводит к некоторой возможной согласованности, которая может или не может быть приемлемым для вашего варианта использования.

Если ничего не помогает, вы можете попробовать запустить кластер на «голом железе» вместо виртуальных машин для значительного увеличения производительности.

В крайнем случае, оцените Erlang на голом железе ... сказал, что ни один разработчик .NET никогда не

person Oliver Tomlinson    schedule 26.04.2017