Tillståndslösa arbetskorn

Som standard skapar körningen Orleans inte mer än en aktivering av ett korn i klustret. Detta är det mest intuitiva uttrycket för modellen Virtuell aktör med varje korn som motsvarar en entitet med en unik typ/identitet. Det finns dock också fall då ett program behöver utföra funktionella tillståndslösa åtgärder som inte är knutna till en viss entitet i systemet. Om klienten till exempel skickar begäranden med komprimerade nyttolaster som måste dekomprimeras innan de kan dirigeras till målintervallet för bearbetning, är sådan dekomprimerings-/routningslogik inte kopplad till en specifik entitet i programmet och kan enkelt skala ut.

StatelessWorkerAttribute När används för en kornklass anger den för körningen att korn i den Orleans klassen ska behandlas som tillståndslösa arbetskorn. Tillståndslösa arbetskorn har följande egenskaper som gör att deras körning skiljer sig mycket från den för normala kornklasser.

1. Körningen Orleans kan och skapar flera aktiveringar av ett tillståndslöst arbetskorn på olika silor i klustret.
2. Begäranden som görs till tillståndslösa arbetskorn körs lokalt så länge silon är kompatibel och därför medför de inte nätverks- eller serialiseringskostnader. Om den lokala silon inte är kompatibel vidarebefordras begäranden till en kompatibel silo.
3. Orleans Runtime skapar automatiskt ytterligare aktiveringar av ett tillståndslöst arbetsintervall om de redan befintliga är upptagna. Det maximala antalet aktiveringar av ett tillståndslöst arbetskorn som körningen skapar per silo begränsas som standard av antalet CPU-kärnor på datorn, såvida det inte uttryckligen anges av det valfria maxLocalWorkers argumentet.
4. På grund av 2 och 3 kan tillståndslösa arbetskornsaktiveringar inte adresseras individuellt. Två efterföljande begäranden till ett tillståndslöst arbetskorn kan bearbetas av olika aktiveringar av den.

Tillståndslösa arbetskorn är ett enkelt sätt att skapa en automatiskt hanterad pool med kornaktiveringar som automatiskt skalas upp och ned baserat på den faktiska belastningen. Körningen söker alltid efter tillgängliga tillståndslösa arbetskornsaktiveringar i samma ordning. På grund av detta skickar den alltid begäranden till den första inaktiva lokala aktiveringen som den kan hitta och kommer bara till den sista om alla tidigare aktiveringar är upptagna. Om alla aktiveringar är upptagna och aktiveringsgränsen inte har nåtts skapar den ytterligare en aktivering i slutet av listan och skickar begäran till den. Det innebär att när antalet begäranden till ett tillståndslöst arbetsintervall ökar och befintliga aktiveringar är upptagna för närvarande, expanderar körningen poolen med dess aktiveringar upp till gränsen. När belastningen minskar och den kan hanteras av ett mindre antal aktiveringar av det tillståndslösa arbetsintervallet kommer aktiveringarna i slutet av listan inte att få begäranden skickade till dem. De blir inaktiva och inaktiveras slutligen av standardprocessen för aktiveringsinsamling. Därför krymper poolen med aktiveringar så småningom för att matcha belastningen.

I följande exempel definieras en tillståndslös arbetskornsklass MyStatelessWorkerGrain med standardgränsen för maximalt aktiveringsnummer.

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

Att göra ett anrop till ett tillståndslöst arbetskorn är detsamma som för andra korn. Den enda skillnaden är att i de flesta fall används ett enda korn-ID, till exempel 0 eller Guid.Empty. Flera korniga ID:er kan användas när du har flera tillståndslösa arbetskornspooler, ett per ID är önskvärt.

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

Den här definierar en tillståndslös arbetskornsklass med högst en kornig aktivering per silo.

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

Observera att StatelessWorkerAttribute inte ändrar återaktiveringen för målkornsklassen. Precis som andra korn är tillståndslösa arbetskorn som standard icke-reentrant. De kan uttryckligen göras reentrant genom att lägga till en ReentrantAttribute i kornklassen.

Tillstånd

Den "tillståndslösa" delen av "tillståndslös arbetare" innebär inte att en tillståndslös arbetare inte kan ha ett tillstånd och endast är begränsad till att köra funktionella åtgärder. Precis som med andra korn kan ett tillståndslöst arbetskorn läsa in och behålla i minnet alla tillstånd som behövs. Det beror bara på att flera aktiveringar av ett tillståndslöst arbetsområde kan skapas på samma och olika silor i klustret, finns det ingen enkel mekanism för att samordna tillstånd som innehas av olika aktiveringar.

Flera användbara mönster omfattar tillståndslös arbetstagarstatus.

Utskalning av objekt med frekvent cache

För objekt med frekvent cache som har högt dataflöde gör det följande att hålla varje sådant objekt i ett tillståndslöst arbetskorn:

1. Skala automatiskt ut i en silo och över alla silor i klustret, och;
2. Gör data alltid lokalt tillgängliga på den silo som tog emot klientbegäran via klientgatewayen, så att begäranden kan besvaras utan extra nätverkshopp till en annan silo.

Minska formatsammansättning

I vissa scenarier måste program beräkna vissa mått över alla korn av en viss typ i klustret och rapportera aggregeringarna med jämna mellanrum. Exempel är att rapportera flera spelare per spelkarta, den genomsnittliga varaktigheten för ett VoIP-samtal osv. Om var och en av de många tusentals eller miljontals kornen skulle rapportera sina mått till en enda global aggregator, skulle aggregatorn omedelbart överbelastas utan att kunna bearbeta strömmen av rapporter. Den alternativa metoden är att omvandla den här uppgiften till ett 2 -steg (eller mer) för att minska formatsammansättningen. Det första skiktet av aggregering görs genom att rapportera korn som skickar sina mått till ett tillståndslöst arbetsföraggregeringsintervall. Körningen Orleans skapar automatiskt flera aktiveringar av det tillståndslösa arbetskornet med varje silo. Eftersom alla sådana anrop bearbetas lokalt utan fjärranrop eller serialisering av meddelandena blir kostnaden för en sådan aggregering betydligt lägre än i ett fjärrfall. Nu kan var och en av de tillståndslösa arbetskornsaktiveringarna före aggregeringen, oberoende eller i samordning med andra lokala aktiveringar, skicka sina aggregerade rapporter till den globala slutliga aggregatorn (eller till ett annat minskningslager om det behövs) utan att överbelasta den.