2017-02-15 15 views
0

. Я ищу, чтобы начать использовать Актеры в Сервисной Ткань, но я хотел просто прояснить несколько вещей, прежде чем начинать.Сохранение состояния в сфере обслуживания. Актеры.

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

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

Я понимаю, что актеры деактивируются, когда они не «используются» (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle), но все еще сохраняют свое состояние и снова активируются, когда к актеру приходит новый вызов. Поэтому теоретически не было бы никакой проблемы, если каждому игроку присваивается тот же идентификатор, который отправляется обратно пользователю, тогда пользователь может вернуться и запросить данные, даже если актер был деактивирован.

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

ответ

2

Картографирование Актеры для пользователей могут быть хорошим подходом при условии, что ваше состояние помечено как Persistent для Актера, состояние сохранено надежно (т. Е. Реплицировано на другие узлы) даже через активацию/деактивацию Актера. Активный Актер просто означает, что он загружен в рабочую память ActorService. Если актер деактивирован и впоследствии называется, он просто активируется. Если вы сопоставляете ActorId с идентификатором пользователя, то тот же идентификатор может быть сохранен внутри самого Актера без необходимости использования вторичного хранилища данных (например, базы данных).

Что характерно для актеров, так это то, что они однопоточные. Это означает, что доступ к актеру и состоянию актера осуществляется последовательным образом. Если доступ к Актеру в первую очередь обусловлен взаимодействием пользователя с вашим API, это не должно быть проблемой. Если у вас, с другой стороны, есть несколько сервисов, которые одновременно обращаются к вашему Актеру, это может стать для вас узким местом, и в этом случае вам может потребоваться использовать надежную услугу с учетом состояния для данных/состояний.

Стойких Актеры

  • однопоточный доступ
  • Изолированного состояние
  • секционированного по ActorId

Актеров без государственного и отдельного упорства

  • однопоточный доступ
  • Разделенного на ActorId
  • государственного доступ/данных ограничены решениями ПЕРСИСТЕНТНОСТИ (SQL пул соединений и т.д.)

Stateful сервис

  • многопоточный доступ
  • Разделенный на 'вручную' назначенным разделом ключа
  • государство надежно содержится в разделе

Stateless служба

  • многопоточный доступ
  • Нет разделения, несколько экземпляров
  • Государство доступа/данные ограничены решения инерционности (SQL пула соединений и т.д.)