2016-07-11 4 views
0

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

Теперь нам нужно добавить ActorRef к «метрическому актору», работающему на каждом узле. Каждый актер в осколке должен отправлять телеметрические данные метрическому актеру - он должен выбрать подходящего актера метрики, который работает локально на том же узле. Причина в том, что метрический актер собирает узел одноранговых данных.

Теперь, я просто думал создать Metric актера в главном методе (который работает сначала на каждом узле):

val mvMetrics : ActorRef = system.actorOf(MetricsActor("mv"), "mvMetrics")

, а затем передать эту ссылку на ClusterSharding inicialisation как часть актеров реквизит объекта :

ClusterSharding(system).start(
     typeName = shardName, 
     entityProps = MyShardActor.props(mvMetrics), 
     settings = ClusterShardingSettings(system), 
     extractEntityId = idExtractor, 
     extractShardId = shardResolver) 

Мой вопрос: что произойдет, если такие созданные актеры мигрируют между узлами, например от узла А -> В? Я могу представить, что перенесенный объект реквизита на узле B остается таким же, как на узле A, поэтому ActorRef остается тем же, и поэтому вновь созданный актер будет отправлять данные метрик в исходный узел A?

Благодаря

ответ

1

Как насчет воспользовавшись ActorRef.path? представьте, что каждый узел имеет свой актер, названный определенным образом, а затем актер будет динамически находить соответствующего метрического актера, используя этот путь.

+0

Да, это была моя вторая идея: иметь узловое имя наблюдающего актера и динамически оценивать его в Shard Actor. Мне просто интересно, если кто-то решил эту проблему по-другому, мне действительно интересно, как реквизит актера обрабатывается внутри осколка во время миграции в кластере :) –

 Смежные вопросы

  • Нет связанных вопросов^_^