Delen via


Staatloze werkrolkorrels

De runtime maakt standaard Orleans niet meer dan één activering van een korrel in het cluster. Dit is de meest intuïtieve expressie van het Virtual Actor-model met elke korrel die overeenkomt met een entiteit met een uniek type/identiteit. Er zijn echter ook gevallen waarin een toepassing functionele staatloze bewerkingen moet uitvoeren die niet zijn gekoppeld aan een bepaalde entiteit in het systeem. Als de client bijvoorbeeld aanvragen verzendt met gecomprimeerde nettoladingen die moeten worden gedecomprimeerd voordat ze kunnen worden doorgestuurd naar het doelgranum voor verwerking, is dergelijke decompressie-/routeringslogica niet gekoppeld aan een specifieke entiteit in de toepassing en kan deze eenvoudig worden uitgeschaald.

Wanneer de StatelessWorkerAttribute klasse wordt toegepast op een graanklasse, geeft deze aan Orleans dat korrels van die klasse moeten worden behandeld als staatloze werkrolkorrels. Staatloze werkrolkorrels hebben de volgende eigenschappen die hun uitvoering heel anders maken dan die van normale graanklassen.

  1. De Orleans runtime kan en maakt meerdere activeringen van een staatloze werkrolkorrel op verschillende silo's van het cluster.
  2. Aanvragen die worden gedaan aan stateless werkrollen worden lokaal uitgevoerd zolang de silo compatibel is, en daarom worden er geen netwerk- of serialisatiekosten in rekening gebracht. Als de lokale silo niet compatibel is, worden aanvragen doorgestuurd naar een compatibele silo.
  3. De Orleans runtime maakt automatisch extra activeringen van een stateless worker-graan als de al bestaande werkrollen bezet zijn. Het maximum aantal activeringen van een staatloze werkrol die door de runtime per silo wordt gemaakt, wordt standaard beperkt door het aantal CPU-kernen op de machine, tenzij dit expliciet is opgegeven met het optionele maxLocalWorkers argument.
  4. Vanwege 2 en 3 zijn stateless werkrolinteractiveringen niet individueel adresseerbaar. Twee volgende aanvragen voor een staatloze werkrol kunnen worden verwerkt door verschillende activeringen ervan.

Staatloze werkrollen bieden een eenvoudige manier om een automatisch beheerde pool met graanactiveringen te maken die automatisch omhoog en omlaag worden geschaald op basis van de werkelijke belasting. De runtime scant altijd in dezelfde volgorde op beschikbare statusloze werkrolactiveringen. Daarom verzendt het altijd aanvragen naar de eerste inactieve lokale activering die kan worden gevonden en wordt alleen naar de laatste geactiveerd als alle vorige activeringen bezet zijn. Als alle activeringen bezet zijn en de activeringslimiet niet is bereikt, wordt er nog een activering gemaakt aan het einde van de lijst en wordt de aanvraag naar de activering verzonden. Dat betekent dat wanneer de frequentie van aanvragen voor een staatloze werkrol toeneemt en bestaande activeringen momenteel bezet zijn, de runtime de pool van de activeringen uitbreidt tot de limiet. Wanneer de belasting echter afneemt en deze kan worden verwerkt door een kleiner aantal activeringen van het staatloze werkrolgranen, worden de activeringen aan de staart van de lijst niet verzonden aanvragen naar hen verzonden. Ze worden niet-actief en uiteindelijk gedeactiveerd door het standaardactiveringsproces. Daarom wordt de groep activeringen uiteindelijk verkleind zodat deze overeenkomt met de belasting.

In het volgende voorbeeld wordt een statusloze werkrolklasse MyStatelessWorkerGrain gedefinieerd met de standaardlimiet voor maximale activeringsnummers.

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

Het aanroepen van een staatloze werkrol is hetzelfde als elk ander graan. Het enige verschil is dat in de meeste gevallen één graan-id wordt gebruikt, bijvoorbeeld 0 of Guid.Empty. Meerdere graan-id's kunnen worden gebruikt bij het hebben van meerdere stateless werkpools, één per id is wenselijk.

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

Deze definieert een staatloze werkrolkorrelklasse met niet meer dan één graanactivering per silo.

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

Houd er rekening mee dat StatelessWorkerAttribute de reentrancy van de doelkorrelklasse niet wordt gewijzigd. Net als andere korrels zijn staatloze werkkorrels standaard niet-reentrant. Ze kunnen expliciet opnieuw worden opgegeven door een aan ReentrantAttribute de graanklasse toe te voegen.

Staat

Het 'staatloze' deel van 'stateless worker' betekent niet dat een staatloze werknemer geen status kan hebben en alleen is beperkt tot het uitvoeren van functionele bewerkingen. Net als elke andere korrel kan een staatloze werkrol worden geladen en in het geheugen blijven. Het is alleen omdat meerdere activeringen van een staatloze werkrol kunnen worden gemaakt op hetzelfde en verschillende silo's van het cluster, is er geen eenvoudig mechanisme om de status te coördineren die wordt gehouden door verschillende activeringen.

Verschillende nuttige patronen zijn stateless worker holding state.

Uitgeschaalde hot-cache-items

Voor hot cache-items die een hoge doorvoer ervaren, maakt het opslaan van elk item in een staatloze werkrol het:

  1. Automatisch uitschalen binnen een silo en over alle silo's in het cluster, en;
  2. Maakt de gegevens altijd lokaal beschikbaar op de silo die de clientaanvraag heeft ontvangen via de clientgateway, zodat de aanvragen kunnen worden beantwoord zonder een extra netwerkhop naar een andere silo.

Aggregatie van stijl verminderen

In sommige scenario's moeten toepassingen bepaalde metrische gegevens voor alle korrels van een bepaald type in het cluster berekenen en de aggregaties periodiek rapporteren. Voorbeelden zijn het rapporteren van verschillende spelers per gamekaart, de gemiddelde duur van een VoIP-oproep, enzovoort. Als elk van de vele duizenden of miljoenen korrels hun metrische gegevens zou rapporteren aan één globale aggregator, zou de aggregator onmiddellijk overbelast raken, zodat de stroom van rapporten niet kan worden verwerkt. U kunt deze taak ook omzetten in een 2 (of meer) stap om de aggregatie van stijl te verminderen. De eerste aggregatielaag wordt uitgevoerd door graan te rapporteren dat hun metrische gegevens naar een staatloze werkrol vooraf aggregatiekorrel worden verzonden. De Orleans runtime maakt automatisch meerdere activeringen van het staatloze werkrolkorrel met elke silo. Omdat dergelijke aanroepen lokaal worden verwerkt zonder externe aanroepen of serialisatie van de berichten, zijn de kosten van deze aggregatie aanzienlijk lager dan in een extern geval. Nu kunnen alle statusloze werkrolactiveringen, onafhankelijk of in coördinatie met andere lokale activeringen, hun geaggregeerde rapporten verzenden naar de globale uiteindelijke aggregator (of naar een andere reductielaag indien nodig) zonder deze te overbelasten.