Grãos de trabalhador apátrida

Por padrão, o Orleans runtime não cria mais de uma ativação de um grain dentro do cluster. Esta é a expressão mais intuitiva do modelo Virtual Ator, onde cada grão corresponde a uma entidade com um tipo/identidade único. No entanto, às vezes, um aplicativo precisa executar operações funcionais sem monitoração de estado não vinculadas a uma entidade específica no sistema. Por exemplo, se um cliente envia solicitações com cargas compactadas que precisam de descompactação antes de rotear para o grão de destino para processamento, essa lógica de descompressão/roteamento não está vinculada a uma entidade específica e pode ser facilmente dimensionada.

Quando você aplica o StatelessWorkerAttribute a uma classe de grãos, ele indica ao Orleans tempo de execução que os grãos dessa classe devem ser tratados como grãos de trabalhador sem estado. Os grãos de trabalhador apátrida têm as seguintes propriedades que tornam sua execução muito diferente das classes de grãos normais:

1. O tempo de execução Orleans pode e efetivamente cria várias ativações de um grão de trabalho sem estado em silos diferentes no cluster.
2. Os grãos de trabalhador sem estado executam solicitações localmente enquanto o silo for compatível e, portanto, não incorrem em custos de rede ou serialização. Se o silo local não for compatível, as solicitações serão encaminhadas para um silo compatível.
3. O Orleans Runtime cria automaticamente ativação adicional para um grão de trabalhador sem estado se os existentes estiverem sobrecarregados. O número máximo de ativações por silo é limitado por padrão pelo número de núcleos de CPU na máquina, a menos que você o especifique explicitamente usando o argumento opcional maxLocalWorkers .
4. Devido aos pontos 2 e 3, as ativações de grãos de trabalhador apátrida não são endereçáveis individualmente. Duas solicitações subsequentes a um grão de trabalhador sem estado podem ser processadas por ativações diferentes.

Os grãos de trabalhador sem estado fornecem uma maneira direta de criar um pool gerenciado automaticamente de ativações de grãos que aumenta e diminui automaticamente com base na carga real. O tempo de execução sempre verifica se há ativações de grãos de trabalhador sem estado disponíveis na mesma ordem. Por isso, ele sempre envia solicitações para a primeira ativação local ociosa que encontra e só prossegue para a última se todas as ativações anteriores estiverem ocupadas. Se todas as ativações estiverem ocupadas e o limite de ativação não tiver sido atingido, ele criará mais uma ativação no final da lista e enviará a solicitação para ela. Isso significa que, quando a taxa de solicitações a um trabalhador sem estado aumenta e as ativações existentes estão todas ocupadas, o tempo de execução expande o pool de ativações até o limite. Por outro lado, quando a carga diminui e um número menor de ativações é capaz de lidar com ela, as ativações no final da lista não receberão solicitações. Eles ficam ociosos e, eventualmente, são desativados pelo processo padrão de recolha de ativações. Assim, o pool de ativações eventualmente encolhe para corresponder à carga.

O exemplo a seguir define uma classe de trabalhador sem estado MyStatelessWorkerGrain com o limite máximo padrão de número de ativações.

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

Fazer uma chamada para um grão trabalhador apátrida é o mesmo que chamar qualquer outro grão. A única diferença é que, na maioria dos casos, você usa um único ID de grão, por exemplo, 0 ou Guid.Empty. Você pode usar vários IDs de grão se for desejável ter vários pools de grãos de trabalhador sem estado (um por ID).

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

Este exemplo define uma classe de trabalhador sem estado com grãos que têm no máximo uma ativação por silo.

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

Observe que StatelessWorkerAttribute não altera a reentrância da classe de grãos de destino. Como qualquer outro grão, os grãos de trabalhadores apátridas não são reentrantes por padrão. Você pode explicitamente torná-los reentrantes adicionando um ReentrantAttribute à classe de grãos.

Estado

A parte "sem estado" de "trabalhador sem estado" não significa que um trabalhador sem estado não possa ter estado ou esteja limitado apenas à execução de operações funcionais. Como qualquer outro grão, um grão de trabalhador apátrida pode carregar e manter na memória qualquer estado que precise. No entanto, como várias ativações de um grão de trabalho sem estado podem ser criadas nos mesmos silos e em silos diferentes no cluster, não existe um mecanismo fácil para coordenar o estado mantido por ativações diferentes.

Vários padrões úteis envolvem trabalhadores apátridas que detêm o Estado.

Itens de cache quente distribuídos

Para itens de cache ativo com alta taxa de transferência, manter cada item em um grão de trabalhador sem estado oferece estes benefícios:

1. Ele se expande automaticamente dentro de um silo e em todos os silos do cluster.
2. Ele torna os dados sempre disponíveis localmente no silo que recebeu a solicitação do cliente por meio de seu gateway de cliente, permitindo que as solicitações sejam respondidas sem um salto de rede extra para outro silo.

Estilo de agregação de redução

Em alguns cenários, os aplicativos precisam calcular determinadas métricas em todos os grãos de um tipo específico no cluster e relatar as agregações periodicamente. Exemplos incluem relatar o número de jogadores por mapa de jogo ou a duração média de uma chamada VoIP. Se cada um dos muitos milhares ou milhões de grãos reportasse suas métricas a um único agregador global, o agregador ficaria imediatamente sobrecarregado e incapaz de processar a enxurrada de relatórios. A abordagem alternativa é transformar essa tarefa em uma agregação em duas etapas (ou mais) no estilo redução. A primeira camada de agregação envolve os grãos de relatório enviando suas métricas para um grão de pré-agregação de trabalhador sem estado. A Orleans runtime cria automaticamente múltiplas ativações do grain de trabalho sem estado em cada silo. Como Orleans processa todas essas chamadas localmente sem chamadas remotas ou serialização de mensagens, o custo dessa agregação é significativamente menor do que em um caso remoto. Agora, cada ativação de grão de trabalhador sem estado de pré-agregação, independentemente ou em coordenação com outras ativações locais, pode enviar seu relatório agregado para o agregador final global (ou para outra camada de redução, se necessário) sem sobrecarregá-lo.