Grains für zustandslose Worker

Standardmäßig erstellt die Orleans-Runtime maximal eine einzelne Aktivierung eines Grains innerhalb des Clusters. Dies ist der intuitivste Ausdruck des Virtual Actor-Modells, bei dem jedes Korn einer Entität mit einem eindeutigen Typ/einer eindeutigen Identität entspricht. Manchmal muss eine Anwendung jedoch funktionslose Vorgänge ausführen, die nicht an eine bestimmte Entität im System gebunden sind. Wenn beispielsweise ein Client Anforderungen mit komprimierten Nutzlasten sendet, die dekomprimiert werden müssen, bevor sie zur Verarbeitung an das Zielkorn weitergeleitet werden, ist diese Dekomprimierungs-/Routinglogik nicht an eine bestimmte Entität gebunden und kann problemlos skaliert werden.

Wenn Sie StatelessWorkerAttribute auf eine Körner-Klasse anwenden, zeigt dies der Orleans-Laufzeit an, dass Körner dieser Klasse als zustandslose Arbeitskörner behandelt werden sollen. Zustandslose Arbeiterkörner weisen die folgenden Eigenschaften auf, die ihre Ausführung sehr von normalen Getreideklassen unterscheiden:

1. Die Orleans Laufzeit kann mehrere Aktivierungen eines zustandslosen Arbeitskorns auf verschiedenen Silos im Cluster erstellen.
2. Zustandslose Arbeiterkornen führen Anforderungen lokal aus, solange das Silo kompatibel ist und somit keine Netzwerk- oder Serialisierungskosten entstehen. Wenn das lokale Silo nicht kompatibel ist, werden Anforderungen an ein kompatibles Silo weitergeleitet.
3. Die Orleans Runtime erstellt automatisch zusätzliche Aktivierungen eines zustandslosen Worker-Grains, wenn die vorhandenen ausgelastet sind. Die maximale Anzahl von Aktivierungen pro Silo ist standardmäßig durch die Anzahl der CPU-Kerne auf dem Computer begrenzt, es sei denn, Sie geben sie explizit mithilfe des optionalen maxLocalWorkers Arguments an.
4. Aufgrund der Punkte 2 und 3 sind zustandslose Arbeiterkornaktivierungen nicht einzeln adressierbar. Zwei nachfolgende Anforderungen an ein zustandsloses Arbeitskorn können von verschiedenen Aktivierungen verarbeitet werden.

Zustandslose Arbeiterkörner bieten eine einfache Möglichkeit, einen automatisch verwalteten Pool von Kornaktivierungen zu erstellen, der basierend auf der tatsächlichen Last automatisch hoch- und runterskaliert wird. Die Runtime sucht immer in der gleichen Reihenfolge nach verfügbaren Aktivierungen von Grains für zustandslose Worker. Aus diesem Grund leitet es Anforderungen immer an die erste nicht ausgelastete lokale Aktivierung weiter und wird nur zur letzten weitergeleitet, wenn alle vorherigen Aktivierungen ausgelastet sind. Wenn alle Aktivierungen ausgelastet sind und der Aktivierungsgrenzwert nicht erreicht wurde, wird am Ende der Liste eine weitere Aktivierung erstellt und die Anforderung an sie gesendet. Dies bedeutet, dass die Laufzeit, wenn die Rate der Anfragen an einen zustandslosen Worker Grain zunimmt und alle vorhandenen Aktivierungen ausgelastet sind, den Pool der Aktivierungen bis zum Limit erweitert. Umgekehrt, wenn die Last sinkt und eine kleinere Anzahl von Aktivierungen sie bewältigen kann, werden die Aktivierungen am Ende der Liste keine Anfragen erhalten. Sie werden inaktiv und werden schließlich durch den standardmäßigen Aktivierungsprozess deaktiviert. Daher schrumpft der Pool der Aktivierungen schließlich so, dass er mit der Last übereinstimmt.

Im folgenden Beispiel wird eine Grain-Klasse für zustandslose Worker (MyStatelessWorkerGrain) mit dem Standardgrenzwert für die maximale Anzahl von Aktivierungen definiert:

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

Ein Anruf an ein zustandsloses Worker-Grain erfolgt auf dieselbe Weise wie bei jedem anderen Grain. Der einzige Unterschied besteht darin, dass Sie in den meisten Fällen eine einzelne Korn-ID verwenden, z. B. 0 oder Guid.Empty. Sie können mehrere Getreide-IDs verwenden, wenn mehrere zustandslose Arbeitskornpools (eine pro ID) wünschenswert sind.

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

In diesem Beispiel wird eine zustandslose Arbeiterkornklasse definiert, bei der pro Silo nicht mehr als eine Aktivierung erfolgt.

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

Beachten Sie, dass StatelessWorkerAttribute die Reentranz der Ziel-Grain-Klasse nicht ändert. Wie bei jedem anderen Getreide werden zustandslose Arbeitskörner standardmäßig nicht erneut beanstandet. Sie können sie explizit erneut aufrufen, indem Sie der Kornklasse einen ReentrantAttribute hinzufügen.

Staat

Der "zustandslose" Teil des "zustandslosen Arbeiters" bedeutet nicht, dass ein zustandsloser Arbeiter keinen Zustand haben kann oder nur auf die Ausführung funktionaler Vorgänge beschränkt ist. Ein Grain für zustandslose Worker kann wie jedes andere Grain jeden benötigten Zustand laden und im Arbeitsspeicher speichern. Da jedoch mehrere Aktivierungen eines zustandslosen Arbeitskorns auf demselben und verschiedenen Silos im Cluster erstellt werden können, gibt es keinen einfachen Mechanismus zum Koordinieren des Zustands, der von verschiedenen Aktivierungen gehalten wird.

Mehrere nützliche Muster umfassen zustandslose Arbeitnehmer, die den Zustand halten.

Verkleinerte Hot-Cache-Elemente

Für Hot-Cache-Elemente mit hohem Durchsatz bietet die Aufbewahrung jedes Elements in einem zustandslosen Arbeitskorn folgende Vorteile:

1. Es skaliert automatisch innerhalb eines Silos und über alle Silos im gesamten Cluster.
2. Sie stellt die Daten immer lokal auf dem Silo zur Verfügung, das die Clientanfrage über das Clientgateway erhalten hat, sodass Anfragen ohne zusätzlichen Netzwerk-Hop zu einem anderen Silo beantwortet werden können.

Aggregation im Reduktionsstil

In einigen Szenarien müssen Anwendungen bestimmte Metriken in allen Körnern eines bestimmten Typs im Cluster berechnen und die Aggregate regelmäßig melden. Beispiele sind das Melden der Anzahl der Spieler pro Spielkarte oder die durchschnittliche Dauer eines VoIP-Anrufs. Wenn jedes der vielen Tausend oder Millionen von Körnern ihre Metriken einem einzigen globalen Aggregator gemeldet hätte, würde der Aggregator sofort überlastet und könnte die Flut von Berichten nicht verarbeiten. Der alternative Ansatz besteht darin, diese Aufgabe in eine zweistufige (oder mehr) reduzierungsbasierte Aggregation umzuwandeln. Die erste Ebene der Aggregation umfasst die Berichtskörner, die ihre Metriken an ein zustandsloses Voraggregationskorn senden. Die Orleans Laufzeit erstellt automatisch mehrere Aktivierungen der zustandslosen Worker-Grain auf jedem Silo. Da Orleans alle derartigen Aufrufe lokal ohne Remoteanrufe oder Nachrichten serialisierung verarbeitet werden, ist die Kosten dieser Aggregation wesentlich geringer als in einem Remotefall. Jetzt kann jede Voraggregation zustandslose Arbeiterkornaktivierung unabhängig oder in Abstimmung mit anderen lokalen Aktivierungen ihren aggregierten Bericht an den globalen endgültigen Aggregator (oder bei Bedarf an eine andere Reduzierungsschicht) senden, ohne sie zu überladen.