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

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

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

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

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

  2. создать один экземпляр каждого актера на сервере и использовать этот экземпляр актера для каждого запроса? Я читал, что актер может обрабатывать только одно сообщение за раз, так что это не может быть горлышко?

  3. сделать что-то еще?

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

61
akka scala

5 ответов

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

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

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

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

31

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

год назад я сделал сравнение между потреблением ресурсов потоковых и основанных на событиях стандартных акторов. И Akka даже лучше, чем event-база.

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

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

23

опции 1) или 2) имеют оба своих недостатка. Итак, давайте использовать options 3) маршрут (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");

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

23

  1. это вполне разумный вариант, но подходит ли он, зависит от особенностей обработки вашего запроса.

  2. Да, конечно, может.

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

8

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

4