Акка - Сколько экземпляров актера вы должны создать?

Я новичок в структуре Akka, и я создаю приложение HTTP-сервера поверх Netty + Akka.

Моя идея до сих пор заключается в создании актера для каждого типа запроса. Например. У меня был бы актер для POST/my-ресурса и другого актера для GET/my-resource.

Где я смущен, как мне нужно заниматься созданием актера? Должен ли я:

  • Создайте нового участника для каждого запроса (я имею в виду для каждого запроса, должен ли я делать TypedActor.newInstance() соответствующего актера)? Как дорого создать новый актер?

  • Создайте один экземпляр каждого актера при запуске сервера и используйте этот экземпляр актера для каждого запроса? Я читал, что актер может обрабатывать только одно сообщение за раз, так что разве это не могло быть горло бутылки?

  • Сделайте что-нибудь еще?

Спасибо за любую обратную связь.

ОТВЕТЫ

Ответ 1

Ну, вы создаете актера для каждого экземпляра изменяемого состояния, которое вы хотите управлять.

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

Если (более вероятно) вы управляете несколькими ресурсами, один актер на экземпляр ресурса обычно идеален, если вы не используете тысячи ресурсов. Хотя вы также можете запускать сторонних пользователей, вы получите странный дизайн, если не думаете о состоянии, к которому обращаются эти запросы - например, если вы просто создаете одного участника в рассылке POST-запроса, вы будете беспокоиться о том, как удержать их от одновременного изменения одного и того же ресурса, что является явным признаком того, что вы неправильно определили своих участников.

Обычно у меня есть довольно тривиальные участники запроса/ответа, основной целью которых является абстрагирование связи с внешними системами. Их связь с субъектами "экземпляра" обычно ограничивается одной парой "запрос/ответ" для выполнения фактического действия.

Ответ 2

Если вы используете Akka, вы можете создать актера за запрос. Акка очень скудна по ресурсам, и вы можете создавать буквально миллионы актеров на довольно обычной куче JVM. Кроме того, они будут потреблять только cpu/stack/threads, когда они действительно что-то делают.

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

Одна из главных моментов Akka, на мой взгляд, заключается в том, что она позволяет вам проектировать вашу систему как "одного актера за использование", где раньше система актеров часто заставляла вас "использовать только участников для общих сервисов" из-за нехватки ресурсов.

Я бы порекомендовал вам перейти на вариант 1.

Ответ 3

Варианты 1) или 2) имеют оба недостатка. Итак, давайте использовать опции 3) Routing (Akka 2.0 +)

Маршрутизатор - это элемент, который действует как балансировщик нагрузки , маршрутизируя запросы другим Акторам, которые будут выполнять требуемую задачу.

Akka предлагает различные реализации маршрутизатора с различной логикой для маршрутизации сообщения (например, SmallestMailboxPool или RoundRobinPool).

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

//This will create 5 instances of the actor ExampleActor
//managed and supervised by a RoundRobinRouter
ActorRef roundRobinRouter = getContext().actorOf(
Props.create(ExampleActor.class).withRouter(new RoundRobinRouter(5)),"router");

Эта процедура хорошо объясняется в этом блоге.

Ответ 4

  • Это довольно разумный вариант, но зависит ли он от специфики обработки ваших запросов.

  • Да, конечно, возможно.

  • Для многих случаев лучше всего просто иметь одного участника, отвечающего на каждый запрос (или, возможно, одного актера в каждом типе запроса), но единственное, что делает этот актер, - это переслать задачу другому актер (или создайте a Future), который фактически выполнит задание.

Ответ 5

Для увеличения обработки последовательных запросов добавьте мастер-актер (Supervisor), который, в свою очередь, будет делегировать рабочим актерам (Дети) (круговой стиль).