Имеет ли смысл когда-либо создавать дочерних акторов внутри метода Receive в AKKA?
Давайте предположим, что мне нужно делегировать некоторый подпроцесс дочернему актеру. Я мог бы создать дочерний актер во время инициализации актера (называемый PreStart в AKKA.NET). Если мне нужно несколько дочерних актеров для параллельной работы, я могу использовать маршрутизаторы AKKA. Я считаю это рекомендуемым подходом.
Однако я мог бы также создать дочерний актер внутри метода Receive и позволить ссылке на экземпляр IActorRef иметь локальную область действия метода Receive. Будет ли такой подход иметь смысл? Это обеспечит какие-либо преимущества по сравнению с описанным выше случаем?
3 ответа
Имеет смысл создавать дочерние акторы в обработчике сообщений, особенно если вы не можете создать их априори, потому что вы создаете их динамически в зависимости от входящих данных.
Ярким примером этого является шаблон Child Per Entity, в котором вы создаете актера для каждого идентификатора объекта. Таким образом, если вы получите сообщение с новым идентификатором, которого вы не получали раньше, вам нужно будет раскрутить нового дочернего актера.
Вы можете увидеть, как пример веб-сканера делает это. Хотя первым соблазном было бы сохранить словарь идентификатора для дочернего субъекта, оказывается, что в этом даже нет необходимости. Как и в примере с веб-сканером, вы можете проверить Children определить, есть ли у этого ребенка уже или нет.
Когда вы создаете дочерних акторов динамически, вы можете дать им ReceiveTimeout чтобы они не пропускали память, живя вечно.
Да. Например, если каждое полученное сообщение запускает какой-либо процесс с отслеживанием состояния, вы должны создать дочерние акторы для обработки этого процесса. Этим дочерним субъектам, возможно, придется отвечать на другие сообщения других участников. Затем может появиться последнее сообщение, в котором говорится о завершении процесса. Вы можете передавать IActorRef как часть сообщения, поэтому концепция локальной области не обязательно применяется.
Другим примером, где актеры создаются динамически, являются шаблоны Extra и Cameo, описанные здесь, и исходный код здесь.
Основная идея шаблона "Камея" заключается в том, чтобы создать перед рабочими (камеями) адаптивный фасад. Он отличается от Router, потому что Facade не находится на пути ответа, он передает весь соответствующий контекст в Cameo и позволяет ему выполнить задание и передать результат непосредственно отправителю (исходного задания).
Дополнительный шаблон такой же, но с анонимным актером. Актер Cameo лучше, потому что он обеспечивает лучшие журналы (с читаемыми именами актеров) и немного лучше структурирует код. Также сложнее закрывать состояние фасада актера.
Итог: создание акторов для каждого запроса позволяет лучше изолировать единицы работы, держать актеров "точки входа" менее занятыми и предоставлять журналы с лучшей областью видимости (что может быть крайне важно для понимания поведения распределенной системы).