Блог

У меня есть служба REST, которая обслуживает только один запрос POST. Я хочу использовать актера для обработки запроса. Однако я не знаю, должен ли я создать одного актера и выводить все запросы, используя этого актера, или я должен создавать актера каждый раз, когда получаю запрос. Каковы плюсы и минусы этих вариантов. Кроме того, как происходит параллельное выполнение, когда я создаю одного актера и использую этого актера для обработки всех моих запросов. Это, безусловно, выглядит как последовательное выполнение. Я бы тоже хотел это понять.

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

Вот почему это сказано

Один актер — это не актер.

Создайте актера-менеджера, который управляет другими актерами. Поскольку актеры довольно дешевы, вы можете без проблем создавать одного актера для каждого запроса. Выполняйте взаимодействия с БД и другие тяжелые вычисления с использованием future и прямых результатов future для обработки запросов актора с использованием pipeTo шаблона.

Используйте актеров только для разделения и распределения работы и используйте фьючерсы для выполнения работы, требующей больших вычислительных ресурсов.

Я бы создал актера по запросу и использовал шаблон «сообщить», чтобы делегировать работу вновь созданному актеру. Если используемая вами платформа REST поддерживает выполнение запроса от другого актера (Spray, Akka-HTTP поддерживает), то вы можете выполнить запрос от этого нового актера. Таким образом, ваш субъект обработки запросов может свободно обрабатывать следующий запрос.

Я нахожу это замечательным ресурсом, который объясняет плюсы и минусы ask amp; tell и для каждого участника запроса. Это может быть полезно для вас.

Я согласен с тем, что сказал @pamu. Актеры дешевы. Но помните, что если когда-либо вы собираетесь использовать одноэлементного актера, не делайте его с сохранением состояния, это вызовет проблемы.

И если вы собираетесь использовать Futures для выполнения интенсивной работы (что вам следует делать). Убедитесь, что вы указали им конкретный ExecutionContext / Dispatcher. Использование глобального диспетчера или ExecutionContext не подходит.

Или в каждом имеющемся у вас API создайте определенного диспетчера для управления числом актеров, которые будут работать с такого рода конечной точкой / api.

Например, у вас есть «/ get / transactions»

укажите диспетчер, который будет порождать только это число потоков. Для этого api.

Преимущество этого в том, что вы можете контролировать количество потоков и ресурсов, используемых вашим приложением. Когда дело доходит до работы с интенсивным трафиком. Это хорошая практика.