Diretrizes e recomendações para coleções confiáveis no Azure Service Fabric

  • Artigo

Esta seção fornece diretrizes para o uso do Reliable State Manager e do Reliable Collections. O objetivo é ajudar os usuários a evitar armadilhas comuns.

Guildelines de coleção confiáveis

As diretrizes são organizadas como recomendações simples prefixadas com os termos Fazer, Considerar, Evitar e Não Fazer.

  • Não modifique um objeto de tipo personalizado retornado por operações de leitura (por exemplo, TryPeekAsync ou TryGetValueAsync). As Coleções Confiáveis, assim como as Coleções Simultâneas, retornam uma referência aos objetos e não uma cópia.
  • Faça uma cópia profunda do objeto retornado de um tipo personalizado antes de modificá-lo. Como structs e tipos internos são pass-by-value, você não precisa fazer uma cópia profunda neles, a menos que contenham campos de referência ou propriedades que você pretende modificar.
  • Não utilizar TimeSpan.MaxValue para tempos limites. Os tempos limite devem ser usados para detetar bloqueios.
  • Não utilize uma transação depois de esta ter sido confirmada, abortada ou eliminada.
  • Não use uma enumeração fora do escopo da transação em que ela foi criada.
  • Não crie uma transação dentro do extrato de using outra transação porque isso pode causar bloqueios.
  • Não crie um estado confiável com IReliableStateManager.GetOrAddAsync e use o estado confiável na mesma transação. Isso resulta em um InvalidOperationException.
  • Certifique-se de que sua IComparable<TKey> implementação está correta. O sistema depende da mesclagem de pontos de IComparable<TKey> verificação e linhas.
  • Use o bloqueio de atualização ao ler um item com a intenção de atualizá-lo para evitar uma determinada classe de bloqueios.
  • Considere manter o número de coleções confiáveis por partição inferior a 1000. Prefira Coleções Confiáveis com mais itens do que Coleções mais Confiáveis com menos itens.
  • Considere manter seus itens (por exemplo, TKey + TValue for Reliable Dictionary) abaixo de 80 KBytes: quanto menor, melhor. Isso reduz a quantidade de uso de heap de objeto grande, bem como os requisitos de E/S de disco e rede. Muitas vezes, ele reduz a replicação de dados duplicados quando apenas uma pequena parte do valor está sendo atualizada. A maneira comum de conseguir isso no Dicionário Confiável, é dividir suas linhas em várias linhas.
  • Considere o uso da funcionalidade de backup e restauração para ter recuperação de desastres.
  • Evite misturar operações de entidade única e operações de várias entidades (por exemplo GetCountAsync, CreateEnumerableAsync) na mesma transação devido aos diferentes níveis de isolamento.
  • Manipule InvalidOperationException. As transações do usuário podem ser abortadas pelo sistema por vários motivos. Por exemplo, quando o Reliable State Manager está alterando sua função para fora do Primário ou quando uma transação de longa duração está bloqueando o truncamento do log transacional. Nesses casos, o usuário pode receber InvalidOperationException indicando que sua transação já foi encerrada. Supondo que o término da transação não foi solicitado pelo usuário, a melhor maneira de lidar com essa exceção é descartar a transação, verificar se o token de cancelamento foi sinalizado (ou se a função da réplica foi alterada) e, se não, criar uma nova transação e tentar novamente.
  • Não aplique operações paralelas ou simultâneas dentro de uma transação. Apenas uma operação de thread de usuário é suportada em uma transação. Caso contrário, causará problemas de fuga de memória e bloqueio.
  • Considere descartar a transação o mais rápido possível após a conclusão da confirmação (especialmente se estiver usando ConcurrentQueue).
  • Não execute nenhum código de bloqueio dentro de uma transação.
  • Quando string é usada como a chave para um dicionário confiável, a ordem de classificação usa o comparador de string padrão CurrentCulture. Observe que a ordem de classificação CurrentCulture é diferente do comparador de cadeia ordinal.
  • Não elimine ou cancele uma transação comprometida. Isso não é suportado e pode falhar o processo de host.

Aqui estão algumas coisas a ter em mente:

  • O tempo limite padrão é de 4 segundos para todas as APIs de coleta confiável. A maioria dos usuários deve usar o tempo limite padrão.
  • O token de cancelamento padrão está CancellationToken.None em todas as APIs de coleções confiáveis.
  • O parâmetro de tipo de chave (TKey) para um dicionário confiável deve implementar GetHashCode() corretamente e Equals(). As chaves devem ser imutáveis.
  • Para obter alta disponibilidade para as Coleções Confiáveis, cada serviço deve ter pelo menos um destino e um tamanho mínimo de conjunto de réplicas de 3.
  • As operações de leitura no secundário podem ler versões que não são confirmadas por quórum. Isso significa que uma versão de dados que é lida de um único secundário pode ser falsamente progredida. As leituras da Primária são sempre estáveis: nunca podem ser falsamente progredidas.
  • A segurança/privacidade dos dados mantidos pela sua aplicação numa recolha fiável é uma decisão sua e está sujeita às proteções fornecidas pela sua gestão de armazenamento; Ou seja, a criptografia de disco do sistema operacional pode ser usada para proteger seus dados em repouso.
  • ReliableDictionary A enumeração usa uma estrutura de dados ordenada por chave. Para tornar a enumeração eficiente, as consolidações são adicionadas a um hash temporário e posteriormente transferidas para o ponto de verificação da estrutura de dados ordenados principal. Adds/Updates/Deletes têm o melhor caso de tempo de execução de O(1) e o pior caso de tempo de execução de O(log n), no caso de verificações de validação sobre a presença da chave. Obtém pode ser O(1) ou O(log n), dependendo se você está lendo de uma confirmação recente ou de uma confirmação mais antiga.

Diretrizes adicionais para coleções confiáveis voláteis

Ao decidir usar coleções confiáveis voláteis, considere o seguinte:

  • ReliableDictionary tem suporte volátil
  • ReliableQueue tem suporte volátil
  • ReliableConcurrentQueue NÃO tem suporte volátil
  • Os serviços persistentes NÃO PODEM tornar-se voláteis. Alterar o sinalizador para false requer recriar todo o HasPersistedState serviço a partir do zero
  • Serviços voláteis NÃO podem ser feitos persistentes. Alterar o sinalizador para true requer recriar todo o HasPersistedState serviço a partir do zero
  • HasPersistedState é uma configuração de nível de serviço. Isso significa que TODAS as coleções serão persistentes ou voláteis. Não é possível misturar coleções voláteis e persistentes
  • A perda de quórum de uma partição volátil resulta em perda completa de dados
  • O backup e a restauração NÃO estão disponíveis para serviços voláteis

Próximos passos