Ziarna procesów roboczych bezstanowych

Domyślnie środowisko uruchomieniowe Orleans tworzy nie więcej niż jedną aktywację ziarna w klastrze. Jest to najbardziej intuicyjne wyrażenie modelu wirtualnego aktora, w którym każde ziarno odpowiada jednostce z unikatowym typem/tożsamością. Jednak czasami aplikacja musi wykonywać funkcjonalne operacje bezstanowe, które nie są powiązane z określoną jednostką w systemie. Jeśli na przykład klient wysyła żądania ze skompresowanymi ładunkami, które wymagają dekompresji przed przekierowaniem do docelowego ziarna do przetwarzania, taka logika dekompresji/przekierowania nie jest powiązana z określoną jednostką i może łatwo skalować w poziomie.

Gdy zastosujesz StatelessWorkerAttribute do klasy ziarna, wskazuje to środowisku wykonawczemu Orleans, że ziarna tej klasy powinny być traktowane jako bezstanowe ziarenka robocze. Bezstanowe ziarna robocze mają następujące właściwości, które sprawiają, że ich wykonywanie znacząco różni się od normalnych klas ziarna:

1. Środowisko Orleans uruchomieniowe może i tworzy wiele aktywacji bezstanowego ziarna procesu roboczego na różnych silosach w klastrze.
2. Bezustannikowe ziarna pracowników wykonują żądania lokalnie, o ile silos jest zgodny, dzięki czemu nie generują kosztów sieci ani serializacji. Jeśli lokalny silos nie jest zgodny, żądania są przekazywane do zgodnego silosu.
3. Środowisko Orleans uruchomieniowe automatycznie tworzy dodatkowe aktywacje bezstanowego ziarna procesu roboczego, jeśli istniejące są zajęte. Maksymalna liczba aktywacji na silos jest domyślnie ograniczona przez liczbę rdzeni procesora CPU na maszynie, chyba że jawnie określisz ją przy użyciu opcjonalnego maxLocalWorkers argumentu.
4. Ze względu na punkty 2 i 3, bezstanowe aktywacje ziarna roboczego nie są indywidualnie adresowalne. Dwa kolejne żądania do bezstanowego procesu roboczego mogą być przetwarzane przez różne aktywacje.

Bezstanowe ziarna pracowników oferują prosty sposób na tworzenie automatycznie zarządzanej puli aktywacji, która dostosowuje swoją skalę w górę i w dół w zależności od rzeczywistego obciążenia. Środowisko uruchomieniowe zawsze skanuje dostępne aktywacje bezstanowe ziarna roboczego w tej samej kolejności. W związku z tym zawsze wysyła żądania do pierwszej bezczynnej aktywacji lokalnej, która zostanie znalezione i przejdzie tylko do ostatniego, jeśli wszystkie poprzednie aktywacje są zajęte. Jeśli wszystkie aktywacje są zajęte, a limit aktywacji nie został osiągnięty, tworzy jeszcze jedną aktywację na końcu listy i wysyła do niej żądanie. Oznacza to, że gdy częstotliwość żądań do bezstanowej jednostki roboczej wzrośnie, a istniejące aktywacje są zajęte, środowisko uruchomieniowe rozszerza pulę aktywacji aż do osiągnięcia limitu. Z drugiej strony, gdy obciążenie spadnie, a mniejsza liczba aktywacji będzie mogła je obsłużyć, aktywacje na końcu listy nie będą otrzymywać żądań. Stają się bezczynne i ostatecznie dezaktywowane przez standardowy proces zbierania aktywacji. W związku z tym pula aktywacji ostatecznie się zmniejsza, aby dopasować je do obciążenia.

W poniższym przykładzie zdefiniowano bezstanową klasę pracownika ziarna z domyślnym maksymalnym limitem liczby aktywacji MyStatelessWorkerGrain.

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

Dzwonienie do bezstanowego pracownika ziarna jest takie samo jak do dowolnego innego ziarna. Jedyną różnicą jest to, że w większości przypadków należy użyć pojedynczego identyfikatora ziarna, na przykład 0 lub Guid.Empty. Można użyć wielu identyfikatorów ziarna, jeśli pożądane jest posiadanie wielu bezstanowych puli zasobów ziarna pracowniczego (jeden na identyfikator).

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

W tym przykładzie zdefiniowano bezstanową klasę procesów roboczych z nie więcej niż jedną aktywacją na silos.

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

Należy pamiętać, że StatelessWorkerAttribute nie zmienia reentrancyjności klasy docelowego ziarna. Podobnie jak każde inne ziarno, bezstanowe ziarna robocze są domyślnie nie-reentrantne. Możesz jawnie uczynić je reentrantnymi, dodając komponent ReentrantAttribute do klasy ziaren.

Państwo

Część "bezstanowa" w "bezstanowym pracowniku" nie oznacza, że bezstanowy pracownik nie może mieć stanu lub jest ograniczony tylko do wykonywania operacji funkcjonalnych. Podobnie jak każde inne ziarno w tym systemie, bezstanowe ziarno robocze może ładować i przechowywać w pamięci dowolny stan, który jest mu potrzebny. Jednak ponieważ wiele aktywacji bezstanowych ziaren roboczych można utworzyć na tym samym silosie i różnych silosach w klastrze, nie ma łatwego mechanizmu koordynowania stanu pomiędzy różnymi aktywacjami.

Kilka przydatnych wzorców obejmuje bezstanowych pracowników posiadających stan.

Skalowane w poziomie elementy gorącej pamięci podręcznej

W przypadku elementów gorącej pamięci podręcznej o wysokiej przepływności przechowywanie każdego elementu w bezstanowym ziarnie procesów roboczych zapewnia następujące korzyści:

1. Automatycznie skaluje się poziomo między silosami oraz we wszystkich silosach w klastrze.
2. Dzięki temu dane są zawsze dostępne lokalnie na silosie, która odebrała żądanie klienta za pośrednictwem bramy klienta, co umożliwia udzielenie odpowiedzi na żądania bez dodatkowego przeskoku sieciowego do innego silosu.

Agregacja w stylu redukcji

W niektórych scenariuszach aplikacje muszą obliczyć niektóre metryki we wszystkich ziarnach określonego typu w klastrze i okresowo zgłaszać agregacje. Przykłady obejmują meldowanie liczby graczy na mapę gry lub średni czas trwania połączenia VoIP. Jeśli każde z wielu tysięcy lub milionów ziaren zgłosiłoby swoje metryki do jednego globalnego agregatora, agregator natychmiast stałby się przeciążony i nie byłby w stanie przetworzyć zalewu zgłoszeń. Alternatywną metodą jest przekształcenie tego zadania w dwuetapową (lub większą) agregację w stylu redukcji. Pierwsza warstwa agregacji obejmuje ziarna raportowania wysyłające metryki do bezstanowego ziarna agregacji procesu roboczego. Środowisko Orleans uruchomieniowe automatycznie tworzy wiele aktywacji bezstanowego ziarna przetwarzającego na każdym silosie. Ponieważ Orleans przetwarza wszystkie takie wywołania lokalnie, bez zdalnych wywołań lub serializacji komunikatów, koszt tej agregacji jest znacznie mniejszy niż w przypadku zdalnym. Teraz każda aktywacja ziarna bezstanowego procesu roboczego, niezależnie lub w koordynacji z innymi aktywacjami lokalnymi, może wysłać zagregowany raport do globalnego agregatora końcowego (lub do innej warstwy redukcji, jeśli to konieczne) bez powodowania przeciążenia.