BT

Consistências Eventuais, Revisitadas

por Boris Lublinsky , traduzido por Douglas Masson em 14 Jan 2009 |

Desenvolver sistemas distribuídos confiáveis em uma escala mundial exige uma troca entre consistência e disponibilidade. No mês passado, O CTO da Amazon, Werner Vogels, postou um artigo descrevendo abordagens para tolerar eventuais consistências de dados em sistemas distribuídos de grande escala.

Conforme discutido neste post da InfoQ:

Um dos aspectos chave do papel da arquitetura de sistemas é o de pesar os requisitos conflitantes e decidir por uma solução, freqüentemente pela negociação de um aspecto contra outro.

Um novo post de Werner Vogels, discutiu como estes requisitos fundamentais influenciam os serviços de infra estrutura, fornecendo recursos para a construção de plataformas computacionais em escala de internet.

Dado o escopo mundial destes sistemas, nós usamos técnicas de replicação de forma ubiquita para garantir performance e alta escalabilidade consistente . Embora a replicação nos aproxime de nossos objetivos, não se pode alcançá-la de uma forma perfeitamente transparente, sob uma série de condições os clientes desses serviços serão confrontados com as conseqüências da utilização de técnicas de replicação no interior dos serviços. Uma das formas em que isto se manifesta é no tipo de consistência de dados que é fornecida, particularmente quando o sistema distribuído base fornece um modelo de consistência eventual para a replicação dos dados. Quando desenhando estes sistemas de larga escala na Amazon, nós utilizamos um conjunto dos princípios orientados e abstrações relacionadas à replicação de dados em larga escala e focamos na troca entre a alta disponibilidade e a consistência de dados.

De acordo com Werner, existem duas formas de olhar para a consistência: a partir do ponto de vista do desenvolvedor/cliente - como eles observam a atualização dos dados e a partir do ponto de vista do servidor - como é o fluxo das atualizações através do sistema e que garantias o sistema pode dar no que diz respeito às atualizações.

Os seguintes elementos devem ser considerados quando se define um modelo de consistência no lado do cliente:

  • Sistema de armazenamento... Alguém deve assumir que por baixo do pano isso é algo de grande escala e altamente distribuído, que é construído para garantir a durabilidade e a disponibilidade...
  • Processo A. Este é um processo que escreve e lê a partir do sistema de armazenamento.
  • Processos B e C. Estes dois processos são independentes do processo A e escrevem e lêem a partir do sistema de armazenamento... Consistência no lado do cliente tem a ver com o como e quando os observadores (neste caso os processos A, B ou C) vêem as atualizações feitas para um objeto de dados em sistemas de armazenamento.
  • Consistência forte. Depois de completar as atualizações, qualquer acesso subseqüente (pelo A, B ou C) irá retornar o valor atualizado.
  • Consistência fraca. O sistema não garante que acessos subseqüentes retornarão o valor atualizado. Uma série de condições precisa ser conhecida antes que o valor seja retornado. O período entre a atualização e o momento em que é garantido que qualquer observador sempre vai olhar o valor atualizado o qual é apelidado como janela de inconsistência.
  • Consistência eventual. Este é uma forma específica de consistência fraca, o sistema de armazenamento garante que se nenhumas atualizações novas sejam feitas para o objeto, eventualmente todos os acessos retornarão o ultimo valor atualizado. Se não ocorrer falhas, o tamanho máximo da janela de inconsistência pode ser determinado baseado nos fatores tais como os atrasos de comunicação, a carga no sistema e o número de réplicas envolvidas no esquema de replicações.

As variações do modelo de consistência no lado do cliente:são:

  • Consistência casual. Se o processo A tem comunicado ao processo B que tem atualizado um item de dado, um acesso subseqüente pelo processo B retornará o valor atualizado, e uma escrita é garantida para substituir a escrita anterior. Acesso pelo processo C que não tem relacionamento casual com processo A está sujeito às normais regras da consistência eventual.
  • Consistência de leitura-da-sua-escrita. Esta é um modelo importante onde o processo A, depois de ter atualizado um item de dados, sempre acessa o valor atualizado e nunca verá o valor antigo. Este é um caso especial do modelo de consistência casual.
  • Consistência de sessão. Esta é uma versão prática do modelo anterior, onde um processo acessa o sistema de armazenamento no contexto de uma sessão. Enquanto a sessão existir, o sistema garante a consistência da leitura-da-sua-escrita... a garantia não sobrepõem as sessões.
  • Consistência de leitura monótona. Se um processo tem visto um valor particular para o objeto, qualquer acesso subseqüente nunca retornará quaisquer valores anteriores.
  • Consistência de escrita monótona . Neste caso o sistema garante serializar a escrita pelo mesmo processo. Sistemas que não garantem este nível de consistência são notoriamente difíceis para programar.

O nível de consistência em um lado do servidor depende de como as atualizações são propagadas entre a réplica de dados (que é uma forma típica de melhorar a taxa de transferência e fornecer a escalabilidade). Consistência fraca/eventual acontece quando nem todas as réplicas de dados participam da operação de atualização e/ou contatado como parte da operação de leitura. Os dois cenários comuns onde esta situação ocorre são replicações sólidas para o escalonamento da leitura e casos com o acesso de dados complicado. Na maioria destes sistemas as atualizações são propagadas de uma maneira lenta para os restantes nodes no conjunto de réplicas. O período até que todas as réplicas tenham sido atualizadas é a janela de inconsistência e todo o sistema é vulnerável para leitura a partir de nodes que ainda não tenham[= recebido as atualizações. O nível de consistência fornecida por um servidor pode ser melhorada através de implementações específicas de comunicação com cliente/servidor ou pelo próprio cliente:

Quer ou não leitura-da-sua-escrita, sessão e consistência monótona podem ser alcançados depende em geral da "rigidez" dos clientes para o servidor que executa o protocolo distribuído para eles. Se este for o mesmo servidor de cada vez, então é relativamente fácil garantir a leitura-da-sua-escrita e as leituras monótonas. Este se torna um pouco mais difícil de controlar o balanceamento de carga e a tolerância de culpa, mas isto é uma solução simples... Às vezes o cliente implementa a leitura-da-sua-escrita e leituras monótonas.. Adicionando versões nas escritas, o cliente descarta os valores de leituras com versões que precedem da última versão vista.

Cada aplicação cliente tem sua própria tolerância à inconsistência fornecida pelo servidor, mas em todos os casos devem estar cientes do nível de consistência que a aplicação do servidor fornece. Há uma série de melhorias práticas para modelo de consistência eventual, como consistência de sessão de nível e leituras monótonas, que fornecem melhores ferramentas para o desenvolvedor.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT