Рабочая роль без отслеживания состояния

По умолчанию среда выполнения Orleans создает в кластере не более одной активации грейна. Это наиболее интуитивно понятное выражение модели виртуального актора, где каждое зернышко соответствует сущности с уникальным типом или идентичностью. Однако иногда приложению необходимо выполнять функциональные операции без отслеживания состояния, не привязанные к определенной сущности в системе. Например, если клиент отправляет запросы с сжатой полезной нагрузкой, которая нуждается в декомпрессии перед маршрутизацией в целевой модуль для обработки, такая логика, отвечающая за распаковку и маршрутизацию, не привязана к определенной сущности и может легко масштабироваться.

При применении StatelessWorkerAttribute к классу зерна оно указывает среде выполнения Orleans, что зерна этого класса должны обрабатываться как рабочие зерна без состояния. Безгосударственная зернистая роль имеет следующие свойства, которые делают её выполнение значительно отличающимся от обычных зернистых классов:

1. Среда Orleans выполнения может создавать несколько активаций рабочей роли без отслеживания состояния в разных оси в кластере.
2. Бесстатусные рабочие зерна выполняют запросы локально, если зерно совместимо с силосом, поэтому не возникают затраты на сеть или сериализацию. Если локальный силос не совместим, запросы перенаправляются в совместимый силос.
3. Среда Orleans выполнения автоматически создает дополнительные активации рабочей роли без отслеживания состояния, если существующие заняты. Максимальное количество активаций на silo по умолчанию ограничено по количеству ядер ЦП на компьютере, если только вы не указали его явным образом с помощью необязательного maxLocalWorkers аргумента.
4. Из-за точек 2 и 3 активации зерна без отслеживания состояния не рассматриваются по отдельности. Два последующих запроса к стермелому зерну могут обрабатываться различными активациями.

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

В следующем примере определяется статический рабочий зернос MyStatelessWorkerGrain по умолчанию с максимальным пределом активаций.

[StatelessWorker]
public class MyStatelessWorkerGrain : Grain, IMyStatelessWorkerGrain
{
    // ...
}

Вызов к зерне без отслеживания состояния совпадает с вызовом любого другого зерна. Единственное различие заключается в том, что в большинстве случаев используется один идентификатор зерна, например 0 или Guid.Empty. Можно использовать несколько идентификаторов зерна, если требуется несколько пулов зерна без отслеживания состояния (по одному на идентификатор).

var worker = GrainFactory.GetGrain<IMyStatelessWorkerGrain>(0);
await worker.Process(args);

В этом примере определяется класс зерна без отслеживания состояния с не более чем одной активацией для каждого узла.

[StatelessWorker(1)] // max 1 activation per silo
public class MyLonelyWorkerGrain : ILonelyWorkerGrain
{
    //...
}

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

Государство

Часть "без отслеживания состояния" в "рабочей роли без отслеживания состояния" не означает, что рабочий без отслеживания состояния не может иметь состояние или ограничен только выполнением функциональных операций. Подобно любому другому компоненту, статический рабочий компонент может загружать и хранить в памяти любое необходимое состояние. Тем не менее, так как в кластере может быть создано несколько активаций рабочего зерна без состояния, которые могут быть созданы в тех же и разных силосах кластера, нет простого механизма для координации состояния, удерживаемого различными активациями.

В нескольких полезных шаблонах безгосударственные работники удерживают состояние.

Масштабируемые элементы горячего кэша

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

1. Он автоматически масштабируется внутри силоса и по всем силосам в кластере.
2. Он делает данные всегда доступными локально в «silo», который получил запрос клиента через свой клиентский шлюз, что позволяет отвечать на запросы без дополнительного сетевого перехода в другой «silo».

Агрегирование в стиле редукции

В некоторых сценариях приложениям необходимо вычислить определенные метрики во всех зернах определенного типа в кластере и периодически сообщать об агрегатах. Примеры включают сообщения о количестве игроков на игровой карте или о средней продолжительности вызова VoIP. Если каждый из многих тысяч или миллионов зерен сообщил свои метрики одному глобальному агрегатору, агрегатор сразу же будет перегружен и не сможет обработать поток отчетов. Альтернативный подход — это превратить эту задачу в агрегацию в стиле reduce, состоящую из двух или более шагов. Первый уровень агрегирования включает в себя зерна отчетности, отправляющие свои метрики в зерно рабочей роли без отслеживания состояния до агрегирования. Среда выполнения Orleans автоматически создает несколько активаций бессостоячных рабочих зерен на каждом силосе. Поскольку Orleans все такие вызовы обрабатываются локально без удаленного вызова или сериализации сообщений, стоимость этой агрегатной обработки значительно меньше, чем в удаленном случае. Теперь каждая активация зерна рабочей роли без состояния для предварительной агрегации, независимо или в координации с другими локальными активациями, может отправлять агрегированный отчёт в глобальный конечный агрегатор (или в другой слой сокращения при необходимости) без перегрузки.