Кластеризация Akka - заставляет акторов оставаться на определенных машинах

У меня есть приложение akka, которое я буду развертывать на многих машинах. Я хочу, чтобы каждое из этих приложений взаимодействовало друг с другом с помощью функций распределенной шины событий публикации / подписки.

Однако, если я настраиваю систему для кластеризации, меня беспокоит, что субъекты для одного приложения могут быть созданы на узле, отличном от того, на котором они были запущены.

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

По сути, мне не нужна эластичность или кластеризация участников, мне просто нужен распределенный pub / sub. Я вижу такие варианты, как синглтон или роли, упомянутые здесь http://letitcrash.com/tagged/spotlight22, но мне было интересно, как это сделать.


person Nick    schedule 19.06.2013    source источник


Ответы (2)


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

(Akka может однажды получить автоматическое разбиение дерева акторов, но это еще даже не указано.)

person Roland Kuhn    schedule 24.06.2013
comment
хм, но синглтон-менеджер запустит актеров на других узлах. Разве разбиение, которое вот-вот будет выпущено, не работает аналогичным образом. Похоже, что это есть в документации. Придется перечитать, хотя, наверное, ошибаюсь. Иначе какой смысл в кластеризации? - person Nick; 05.07.2013
comment
@Nick См. Этот пример, в котором показано, как обеспечить создание определенных субъектов только на одном компьютере stackoverflow.com/questions/24213196/ - person simbo1905; 19.10.2014

Я считаю, что это не лучший способ использовать эластичную кластеризацию. Но мы также рассматривали ту же проблему и обнаружили, что может быть полезно распределить акторов по узлам с помощью хэша идентификатора объекта (например, осколков базы данных). Например, на каждом узле мы создаем один NodeRouterActor, который передает сообщения нескольким WorkerActor. Когда мы отправляем сообщение NodeRouterActor, он выбирает узел конечной точки, просматривая его в хеш-таблице по ключу id % nodeCount, затем конечная точка NodeRouterActor передает сообщение конкретному WorkerActor, который контролирует объект.

person andrey.feoktistov    schedule 04.07.2013