Поделиться через

Управление состоянием Надежных акторов

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

Сохраняемость состояния и репликация

Все надежные акторы считаются с состоянием, так как каждый экземпляр актора сопоставляется с уникальным идентификатором. Это означает, что повторяющиеся вызовы одного и того же идентификатора субъекта направляются в один и тот же экземпляр субъекта. В бездеcтaтусной системе, наоборот, вызовы клиентов не гарантированно будут направляться на один и тот же сервер каждый раз. По этой причине службы акторов всегда состояние.

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

  • Сохраняемое состояние: состояние сохраняется на диске и реплицируется на три или более реплик. Сохраняемое состояние — это самый надежный вариант хранилища состояний, где состояние может сохраняться даже после катастрофического сбоя кластера.
  • Нестабильное состояние: состояние реплицируется на три или более реплик и хранится только в памяти. Неустойчивое состояние обеспечивает устойчивость к сбою узла и сбою субъекта, а также во время обновлений и балансировки ресурсов. Однако состояние не сохраняется на диске. Таким образом, если все реплики будут потеряны одновременно, то состояние будет утрачено.
  • Не сохраняемое состояние: состояние не реплицируется или записывается на диск, используется только для субъектов, которые не должны надежно поддерживать состояние.

Каждый уровень сохраняемости — это просто другой поставщик состояний и конфигурация репликации службы. Независимо от того, записывается ли состояние на диск, это зависит от поставщика состояния — компонента надежного сервиса, который хранит состояние. Репликация зависит от того, с каким количеством реплик развернута служба. Как и в случае с надежными службами, поставщик состояния и количество реплик можно легко задать вручную. Платформа субъектов предоставляет атрибут, который при использовании в субъекте автоматически выбирает поставщика состояний по умолчанию и автоматически создает параметры для количества реплик для достижения одного из этих трех параметров сохраняемости. Атрибут StatePersistence не наследуется производным классом. Каждый тип актора должен предоставлять свой уровень сохранения состояния (StatePersistence).

Сохраняемое состояние

[StatePersistence(StatePersistence.Persisted)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.Persisted)
class MyActorImpl  extends FabricActor implements MyActor
{
}

Этот параметр использует поставщик состояний, который хранит данные на диске и автоматически задает число реплик службы 3.

Изменяемое состояние

[StatePersistence(StatePersistence.Volatile)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.Volatile)
class MyActorImpl extends FabricActor implements MyActor
{
}

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

Отсутствие сохранённого состояния

[StatePersistence(StatePersistence.None)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.None)
class MyActorImpl extends FabricActor implements MyActor
{
}

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

Значения по умолчанию и созданные параметры

При использовании атрибута StatePersistence поставщик состояний автоматически подбирается для вас во время выполнения, когда служба акторов запускается. Однако число реплик устанавливается во время компиляции инструментами сборки акторов Visual Studio. Средства сборки автоматически создают службу по умолчанию для акторов в ApplicationManifest.xml. Параметры создаются для минимального размера набора реплик и целевого набора реплик.

Эти параметры можно изменить вручную. Но при каждом StatePersistence изменении атрибута параметры задаются значениями размера реплики по умолчанию для выбранного StatePersistence атрибута, переопределяя все предыдущие значения. Другими словами, значения, заданные в ServiceManifest.xml, переопределяются только во время сборки при изменении значения атрибута StatePersistence .

<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application12Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <Parameters>
      <Parameter Name="MyActorService_PartitionCount" DefaultValue="10" />
      <Parameter Name="MyActorService_MinReplicaSetSize" DefaultValue="3" />
      <Parameter Name="MyActorService_TargetReplicaSetSize" DefaultValue="3" />
   </Parameters>
   <ServiceManifestImport>
      <ServiceManifestRef ServiceManifestName="MyActorPkg" ServiceManifestVersion="1.0.0" />
   </ServiceManifestImport>
   <DefaultServices>
      <Service Name="MyActorService" GeneratedIdRef="77d965dc-85fb-488c-bd06-c6c1fe29d593|Persisted">
         <StatefulService ServiceTypeName="MyActorServiceType" TargetReplicaSetSize="[MyActorService_TargetReplicaSetSize]" MinReplicaSetSize="[MyActorService_MinReplicaSetSize]">
            <UniformInt64Partition PartitionCount="[MyActorService_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
         </StatefulService>
      </Service>
   </DefaultServices>
</ApplicationManifest>

Диспетчер состояний

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

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

Диспетчер состояний предоставляет общие методы для управления состоянием, аналогичные тем, что используются в Reliable Dictionary.

Примеры управления состоянием актера, доступ, сохранение и удаление состояния Надежных Актеров.

Лучшие практики

Ниже приведены некоторые рекомендации и советы по устранению неполадок для управления состоянием актора.

Сделать состояние субъекта как можно более детализированным

Это важно для производительности и использования ресурсов приложения. Каждый раз, когда происходит запись или обновление в "именованное состояние" субъекта, все значение, соответствующее этому "именованному состоянию", сериализуется и отправляется по сети вторичным репликам. Вторичные файлы записывают его на локальный диск и отвечают обратно на первичную реплику. Когда первичный получает подтверждения из кворума вторичных реплик, он записывает состояние на локальный диск. Например, предположим, что значение — это класс, имеющий 20 членов и размер 1 МБ. Даже если вы изменили только один из членов класса размером 1 КБ, вы всё равно несете расходы на сериализацию, передачу данных по сети и запись на диск для целого объема 1 МБ. Аналогичным образом, если значение является коллекцией (например, списком, массивом или словарем), вы платите за полную коллекцию, даже если изменить один из его членов. Интерфейс StateManager класса актера похож на словарь. Всегда следует моделировать структуру данных, представляющую состояние субъекта поверх этого словаря.

Правильное управление жизненным циклом субъекта

У вас должна быть четкая политика управления размером состояния в каждом разделе службы акторов. Ваша служба акторов должна иметь фиксированное количество акторов и повторно использовать их как можно больше. Если вы постоянно создаете новых актеров, их необходимо удалить, как только они завершат свою работу. Платформа субъектов сохраняет некоторые метаданные о каждом существующем субъекте. Удаление всех состояний субъекта не удаляет метаданные об этом субъекте. Необходимо удалить субъект (см. удаление субъектов и их состояние), чтобы удалить все сведения о нем, хранящиеся в системе. В качестве дополнительной проверки необходимо запросить службу субъектов (см. перечисление субъектов) один раз в некоторое время, чтобы убедиться, что количество субъектов находятся в ожидаемом диапазоне.

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

Дальнейшие действия

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

Далее узнайте больше о диагностике субъектов и мониторинге производительности.

  • Last updated on