Orleans grain directory

Korrels hebben stabiele logische identiteiten en kunnen worden geactiveerd (geïnstantieerd) en vaak gedeactiveerd gedurende de levensduur van de toepassing, maar maximaal één activering van graan op elk moment bestaat. Telkens wanneer een graan wordt geactiveerd, kan het op een andere silo in het cluster worden geplaatst. Wanneer een korrel wordt geactiveerd in het cluster, wordt deze geregistreerd in het globale register, de graanmap. Dit zorgt ervoor dat volgende aanroepen van dat graan worden geleverd aan die activering van het graan en dat er geen andere activeringen (instanties) van dat graan worden gemaakt. De graanmap is verantwoordelijk voor het behouden van een toewijzing tussen een graanidentiteit en waar (welke silo) de huidige activering zich bevindt.

Orleans Standaard wordt een ingebouwde gedistribueerde map in het geheugen gebruikt. Deze map is uiteindelijk consistent en gepartitioneerd in alle silo's in het cluster in een vorm van een gedistribueerde hash-tabel.

Vanaf 3.2.0 worden Orleans ook pluggable implementaties van grain directory ondersteund.

Twee dergelijke invoegtoepassingen zijn opgenomen in de release 3.2.0:

• Een Azure Table-implementatie: Microsoft.Orleans. GrainDirectory.AzureStorage
• Een Redis Store-implementatie: Microsoft.Orleans. GrainDirectory.Redis

U kunt configureren welke grain directory-implementatie moet worden gebruikt per graantype en u kunt zelfs uw implementatie injecteren.

Welke graanmap moet u gebruiken?

U wordt aangeraden altijd te beginnen met de standaardmap (ingebouwde gedistribueerde map in het geheugen). Hoewel het uiteindelijk consistent is en af en toe dubbele activering toestaat wanneer het cluster instabiel is, is de ingebouwde map zelfvoorzienend zonder externe afhankelijkheden, is er geen configuratie vereist en is de hele tijd in productie gebruikt.

Wanneer u ervaring hebt met Orleans en een use-case hebt voor een graanmap met sterkere garantie voor één activering en/of het aantal graan wilt minimaliseren dat wordt gedeactiveerd wanneer een silo in het cluster wordt afgesloten, kunt u overwegen een opslaggebaseerde implementatie van graanmap te gebruiken, zoals de Redis-implementatie. Probeer het eerst te gebruiken voor een of een paar graantypen, te beginnen met degenen die lang leven en een aanzienlijke hoeveelheid status of een duur initialisatieproces hebben.

Configuratie

Standaard hoeft u niets te doen; de in-memory grain-map wordt automatisch gebruikt en gepartitioneerd in het cluster. Als u een niet-standaard grain directory-configuratie wilt gebruiken, moet u de naam opgeven van de directory-invoegtoepassing die u wilt gebruiken. Dit kan worden gedaan via een kenmerk van de graanklasse en met afhankelijkheidsinjectie en de directory-invoegtoepassing met die naam tijdens de siloconfiguratie.

Korrelconfiguratie

Geef de naam van de grain directory-invoegtoepassing op met de GrainDirectoryAttributevolgende:

[GrainDirectory(GrainDirectoryName = "my-grain-directory")]
public class MyGrain : Grain, IMyGrain
{
    // ...
}

Siloconfiguratie

Hier configureren we de implementatie van redis grain directory:

siloBuilder.AddRedisGrainDirectory(
    "my-grain-directory",
    options => options.ConfigurationOptions = redisConfiguration);

De Azure Grain-map is als volgt geconfigureerd:

siloBuilder.AddAzureTableGrainDirectory(
    "my-grain-directory",
    options => options.ConnectionString = azureConnectionString);

U kunt meerdere mappen met verschillende namen configureren voor verschillende graanklassen:

siloBuilder
    .AddRedisGrainDirectory(
        "redis-directory-1",
        options => options.ConfigurationOptions = redisConfiguration1)
    .AddRedisGrainDirectory(
        "redis-directory-2",
        options => options.ConfigurationOptions = redisConfiguration2)
    .AddAzureTableGrainDirectory(
        "azure-directory",
        options => options.ConnectionString = azureConnectionString);