Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per impostazione predefinita, il runtime Orleans non crea più di un'attivazione di un grain all'interno del cluster. Si tratta dell'espressione più intuitiva del modello Virtual Actor, in cui ogni granularità corrisponde a un'entità con un tipo/identità univoco. Tuttavia, a volte un'applicazione deve eseguire operazioni senza stato funzionali non associate a una particolare entità nel sistema. Ad esempio, se un client invia richieste con payload compressi che richiedono la decompressione prima dell'instradamento all'entità target per l'elaborazione, tale logica di decompressione/instradamento non è associata a un'entità specifica e può facilmente scalare.
Quando applichi il StatelessWorkerAttribute a una classe di grani, indica al runtime Orleans che i granelli di quella classe devono essere trattati come granelli di lavoro senza stato. I grani di lavoro senza stato hanno le proprietà seguenti che ne rendono l'esecuzione molto diversa dalle normali classi di granularità:
- Il Orleans runtime può creare e crea più attivazioni di un grano worker senza stato su silo diversi nel cluster.
- I grani di lavoro senza stato eseguono richieste in locale, purché il silo sia compatibile, pertanto non si verificano costi di rete o serializzazione. Se il silo locale non è compatibile, le richieste vengono inoltrate a un silo compatibile.
- Il Orleans Runtime crea automaticamente attivazioni aggiuntive di un'unità di lavoro senza stato se quelle esistenti sono occupate. Il numero massimo di attivazioni per silo è limitato per impostazione predefinita dal numero di core della CPU sulla macchina, a meno che non lo specifichi esplicitamente usando l'argomento facoltativo
maxLocalWorkers
. - A causa dei punti 2 e 3, le attivazioni con granularità di lavoro senza stato non sono indirizzabili singolarmente. Due richieste successive a un livello di lavoro senza stato potrebbero essere elaborate da attivazioni diverse.
I grani di lavoro senza stato offrono un modo semplice per creare un pool gestito automaticamente di attivazioni granulari che aumentano e riduce automaticamente in base al carico effettivo. Il runtime analizza sempre le attivazioni della granularità di lavoro senza stato disponibili nello stesso ordine. Per questo motivo, invia sempre le richieste alla prima attivazione locale inattiva che trova e procede all'ultima solo se tutte le attivazioni precedenti sono occupate. Se tutte le attivazioni sono occupate e il limite di attivazione non è stato raggiunto, crea un'altra attivazione alla fine dell'elenco e invia la richiesta. Ciò significa che quando il tasso di richieste a un grain lavoratore senza stato aumenta e le attivazioni esistenti sono tutte occupate, il runtime espande il numero delle attivazioni fino al limite. Viceversa, quando il carico scende e un numero minore di attivazioni può gestirlo, le attivazioni alla fine dell'elenco non riceveranno richieste. Diventano inattive e alla fine vengono disattivate dal processo standard di raccolta delle attivazioni. Di conseguenza, il pool di attivazioni alla fine si riduce in modo che corrisponda al carico.
Nell'esempio seguente viene definita una classe MyStatelessWorkerGrain
di granularità di lavoro senza stato con il limite massimo di attivazione predefinito.
[StatelessWorker]
public class MyStatelessWorkerGrain : Grain, IMyStatelessWorkerGrain
{
// ...
}
Effettuare una chiamata a un grain senza stato è come chiamare qualsiasi altro tipo di grain. L'unica differenza è che nella maggior parte dei casi si usa un SINGOLO ID granulare, ad esempio 0
o Guid.Empty. È possibile utilizzare più ID di "grain" se è auspicabile avere più pool di "grain" di lavoro senza stato (uno per ID).
var worker = GrainFactory.GetGrain<IMyStatelessWorkerGrain>(0);
await worker.Process(args);
In questo esempio viene definita una classe di granularità di lavoro senza stato senza più di un'attivazione per silo.
[StatelessWorker(1)] // max 1 activation per silo
public class MyLonelyWorkerGrain : ILonelyWorkerGrain
{
//...
}
Si noti che StatelessWorkerAttribute non modifica la ri-entrabilità della classe grain di destinazione. Come qualsiasi altro grano, i grani di lavoro senza stato non sono reentrant per impostazione predefinita. È possibile renderli rientranti in modo esplicito aggiungendo un ReentrantAttribute alla classe grana.
stato
La parte "senza stato" di "lavoratore senza stato" non significa che un lavoratore senza stato non possa avere uno stato o sia limitato solo all'esecuzione di operazioni funzionali. Come qualsiasi altro tipo di granularità, un granulare di lavoro senza stato può caricare e mantenere in memoria qualsiasi stato necessario. Tuttavia, poiché più attivazioni di un granulare di lavoro senza stato possono essere create nello stesso silo e in silo diversi nel cluster, non esiste un meccanismo semplice per coordinare lo stato mantenuto da attivazioni diverse.
Diversi modelli utili coinvolgono lavoratori senza stato che mantengono lo stato.
Elementi della cache ad accesso frequente con scalabilità orizzontale
Per gli elementi della cache ad accesso frequente con velocità effettiva elevata, il mantenimento di ogni elemento in un livello di lavoro senza stato offre questi vantaggi:
- Si scala automaticamente all'interno di un silo e attraverso tutti i silo nel cluster.
- Rende i dati sempre disponibili localmente sul silo che ha ricevuto la richiesta dal client tramite il proprio gateway, consentendo di rispondere alle richieste senza un passaggio di rete extra verso un altro silo.
Aggregazione secondo lo stile Reduce
In alcuni scenari, le applicazioni devono calcolare determinate metriche in tutti i grani di un particolare tipo nel cluster e segnalare periodicamente le aggregazioni. Gli esempi includono la segnalazione del numero di giocatori per mappa di gioco o la durata media di una chiamata VoIP. Se ognuno dei molti migliaia o milioni di chicchi dovesse segnalare le proprie metriche a un singolo aggregatore globale, l'aggregatore si sovraccaricherebbe immediatamente e sarebbe incapace di elaborare il flusso di report. L'approccio alternativo consiste nel trasformare questa attività in un'aggregazione in due passaggi (o più) di tipo reduce. Il primo livello di aggregazione prevede l'invio da parte dei grani di reporting delle loro metriche a un lavoratore senza stato per la pre-aggregazione. Il Orleans runtime crea automaticamente più attivazioni del granulo di lavoro senza stato in ogni silo. Poiché Orleans elabora tutte queste chiamate in locale senza chiamate remote o serializzazione di messaggi, il costo di questa aggregazione è significativamente inferiore rispetto a un caso remoto. A questo punto, ogni attivazione della granularità di lavoro senza stato di pre-aggregazione, indipendentemente o in coordinamento con altre attivazioni locali, può inviare il report aggregato all'aggregatore finale globale (o a un altro livello di riduzione, se necessario) senza sovraccaricarlo.