Технически, это немного и того, и другого.
Поскольку актеры являются однопотоковыми, в акторе может одновременно выполняться только одна операция.
SF Actor использует подход Ask, где каждый вызов ожидает ответа, вызывающие абоненты будут выполнять вызовы и будут ждать ответов, если субъект получает слишком много вызовов от клиентов, и этот субъект слишком сильно зависит от внешних компонентов, это обработка каждого вызова займет слишком много времени, а все остальные клиентские вызовы будут поставлены в очередь и, возможно, в какой-то момент произойдут сбои, поскольку они будут ожидать слишком долго и времени ожидания.
Это не будет большой проблемой для актеров, использующих подход Tell, таких как Akka, потому что он не ждет ответа, он просто отправляет сообщение в почтовый ящик и получает сообщение с ответом (когда это применимо) , но задержка между запросом и ответом все еще будет проблемой, потому что слишком много сообщений ожидает обработки одним субъектом. С другой стороны, это может увеличить сложность, если одна команда не выполнена, и есть 2 или 3 последовательности событий, которые сработали, прежде чем вы узнаете ответ для первого (здесь это не является областью действия, но вы связываете это с примером ниже).
Что касается второго пункта, то основная идея актера заключается в том, чтобы быть самодостаточным, если он слишком сильно зависит от внешних зависимостей, возможно, вам следует переосмыслить дизайн и оценить, действительно ли актор является лучшим проектом для решения проблемы.
Автономные акторы являются масштабируемыми, они не зависят от внешнего диспетчера состояний для управления своим собственным состоянием, они не будут зависеть от других акторов при выполнении своих задач, они могут масштабироваться независимо друг от друга.
Пример:
Actor1 (из ActorTypeA) зависит от Actor2 (из ActorTypeB) для выполнения операции.
Чтобы сделать его более дружелюбным к человеку, скажем:
- ActorTypeA - это корзина для электронной коммерции
- ActorTypeB - это управление запасами
- Actor1 - корзина для пользователя 1
- Actor2 - запас для продукта A
Всякий раз, когда клиент (пользователь) взаимодействует со своей корзиной покупок, добавляя или удаляя товары, он отправляет команды добавления и удаления Actor1 для управления своей собственной корзиной. В этом сценарии зависимость один к одному, когда другой пользователь перейдет на веб-сайт, для него будет создан другой участник, который будет управлять своей корзиной. В обоих случаях у них будут свои актеры.
Давайте теперь скажем: всякий раз, когда товар помещается в корзину, он будет зарезервирован на складе, чтобы избежать двойной продажи одного и того же товара.
В этом случае оба субъекта будут пытаться зарезервировать продукты в Actor2, и из-за однопоточной природы Актеров только первый из них будет успешным, а второй будет ожидать завершения первого и завершится неудачей, если продукта нет на складе. больше. Кроме того, второй пользователь не сможет добавлять или удалять какие-либо товары в своей корзине, поскольку первая операция ожидает завершения. Теперь увеличьте эти числа на тысячи и посмотрите, как быстро развивается проблема и происходит сбой масштабируемости.
Это всего лишь небольшой и простой пример, поэтому второй пункт относится не только к внешним зависимостям, но и к внутренним, каждая операция вне субъекта снижает его масштабируемость.
Сказал, что вам следует как можно больше избегать внешних (вне субъекта) зависимостей, но это не преступление, если это необходимо, но вы уменьшите масштабируемость, когда внешняя зависимость ограничивает его масштабирование независимо.
Этот другой SO вопрос Я ответил, что может быть также интересен для вас.