Можем ли мы иметь глобальное состояние в системах на основе акторов?

Question

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

С практической точки зрения, что происходит с обновлениями сущности (например, БД) от нескольких участников в такой системе?

Answer 1

Модель субъекта, предназначенная для решения проблемы с любым изменяемым общим состоянием другим способом - субъект должен инкапсулировать ее. Поэтому, если вам нужно, чтобы что-то было разделено между актерами - это должен быть актер с этим состоянием и протоколом для работы с ним. Если вы хотите обновить БД от разных участников - извлеките ответственного за это субъекта и предоставьте API или протокол для других участников для обновления БД. Или сделайте несколько акторов для обработки обновлений БД и маршрутизации сообщений между ними (см. Более подробную информацию: https://doc.akka.io/docs/akka/current/typed/routers.html)

Общий подход - подумайте об общем состоянии, как об акторе, совместно используемом между актерами (через ActorRef) и API состояния в качестве сообщений для этого актера.

Answer 2

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

Не передавать изменчивые объекты между актерами. Для того, чтобы обеспечить это, предпочитайте неизменные сообщения. Если инкапсуляция акторов нарушается, выставляя их изменяемое состояние извне, вы возвращаетесь в нормальную Java землю параллелизма со всеми недостатками.

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

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

Обычно операции чтения БД (CRUD) могут выполняться непосредственно любым субъектом. Для этого необходимо выполнить это. возьмите на себя ответственность за актера и используйте его от других актеров.

Дайте мне знать, если это поможет !!