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

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

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

1. Среда Orleans выполнения может создавать несколько активаций рабочей роли без отслеживания состояния в разных оси кластера.
2. Запросы, сделанные к зернам рабочих без отслеживания состояния, выполняются локально, пока silo совместим, и поэтому они не будут нести затраты на сеть или сериализацию. Если локальный silo несовместим, запросы перенаправляются в совместимый silo.
3. Среда Orleans выполнения автоматически создает дополнительные активации рабочей роли без отслеживания состояния, если уже существующие заняты. Максимальное количество активаций рабочей роли без отслеживания состояния, создаваемых средой выполнения, ограничено по умолчанию по количеству ядер ЦП на компьютере, если не указано явным образом необязательным 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 не изменяет повторное размещение целевого класса зерна. Точно так же, как и любые другие зерна, без отслеживания состояния рабочие зерна по умолчанию не повторно используются. Их можно явно выполнить повторно, добавив его ReentrantAttribute в класс зерна.

State

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

Несколько полезных шаблонов включают состояние хранения без отслеживания состояния рабочей роли без отслеживания состояния.

Горизонтальное масштабирование элементов горячего кэша

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

1. Автоматическое горизонтальное масштабирование в пределах сило и между всеми оси в кластере и;
2. Делает данные всегда доступными локально в silo, получившей запрос клиента через его клиентский шлюз, чтобы запросы можно было ответить без дополнительного прыжка сети в другой silo.

Уменьшение агрегирования стиля

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