Consistência do Cloud Storage

Esta página explica que operações do Cloud Storage são fortemente consistentes e quais são eventualmente consistentes. No caso de objetos memorizáveis em cache e legíveis publicamente, controla o grau de consistência das operações nos objetos.

Operações fortemente consistentes

O Cloud Storage oferece uma forte consistência global para as seguintes operações:

  • Listagem de contentores
  • Bucket read-after-create
  • Bucket read-after-metadata-update
  • Bucket read-after-delete
  • Objeto de leitura após escrita
  • Object read-after-metadata-update
  • Objeto lido após eliminação
  • Listagem de objetos

Quando escreve um objeto no Cloud Storage, por exemplo, quando carrega, compõe ou copia um objeto, o objeto fica imediatamente disponível para leitura e operações de metadados assim que recebe uma resposta de êxito ao seu pedido de escrita. Isto aplica-se a todos os contentores e a todas as classes de armazenamento, e aplica-se tanto à criação de novos objetos como à substituição de objetos existentes. O Cloud Storage também oferece consistência de leitura após a criação, leitura após a atualização de metadados, leitura após a eliminação e listagem para recursos como pastas e pastas geridas.

Uma vez que as escritas são fortemente consistentes, nunca recebe uma resposta ou dados desatualizados para uma operação de leitura após escrita ou leitura após atualização de metadados de um objeto, mesmo para contentores localizados em regiões duplas ou multirregiões.404 Not Found No raro caso de os seus dados ainda não terem sido replicados em todas as regiões, mas a localização onde o objeto foi escrito pela primeira vez ficar indisponível, as tentativas de aceder ao objeto devolvem uma resposta de erro repetível 500.

A forte consistência global também se aplica às operações de eliminação em objetos. Se um pedido de eliminação for bem-sucedido, uma tentativa imediata de transferir o objeto ou os respetivos metadados resulta num código de estado 404 Not Found. Recebe o erro 404 porque o objeto já não existe depois de a operação de eliminação ser bem-sucedida.

As listas de contentores e as listas de objetos são fortemente consistentes: quando cria um contentor ou um objeto e, em seguida, executa imediatamente a operação list relevante, o contentor ou o objeto recém-criado aparece na lista devolvida.

Para os contentores, embora as atualizações de metadados sejam fortemente consistentes para as operações de leitura após a atualização de metadados, as alterações de configuração resultantes podem demorar a propagar-se. Por exemplo, se ativar a criação de versões de objetos num contentor, deve aguardar, pelo menos, 30 segundos antes de eliminar ou substituir objetos.

Da mesma forma, para as chaves HMAC, existe um atraso de até 3 minutos entre o momento em que pede para alterar o estado da chave e o momento em que a alteração do estado entra em vigor. Por exemplo, se desativar uma chave HMAC, deve aguardar, pelo menos, 3 minutos antes de fazer um pedido para eliminar a chave, porque as tentativas de o fazer nos primeiros 3 minutos podem falhar.

Operações eventualmente consistentes

As seguintes operações acabam por ser consistentes:

  • Conceder ou revogar o acesso a recursos.
  • Recriar contentores após a eliminação.

Normalmente, estas operações demoram cerca de um minuto a entrar em vigor. Em alguns casos, pode demorar mais alguns minutos.

Por exemplo, se remover o acesso de um utilizador a um contentor, esta alteração é imediatamente refletida nos metadados do contentor. No entanto, o utilizador pode continuar a ter acesso ao contentor durante um curto período.

Os contentores recriados após a eliminação podem demorar vários minutos a ficar acessíveis.

Controlo e consistência da cache

Os objetos em cache que são legíveis publicamente podem não apresentar uma consistência forte. Se permitir que um objeto seja colocado em cache e o objeto estiver na cache quando for atualizado ou eliminado, o objeto em cache não é atualizado nem eliminado até o respetivo tempo de vida da cache expirar.

A duração total da cache de um objeto é definida pelos Cache-Control metadados associados ao objeto. Os metadados Cache-Control podem ser definidos através de um cabeçalho de pedido Cache-Control incluído no carregamento inicial do objeto ou numa atualização subsequente dos metadados do objeto. Uma vez que controla os metadados, também controla o grau de consistência dos objetos em cache.Cache-Control Além disso, embora os pedidos do objeto possam incluir o respetivo cabeçalho Cache-Control, estes cabeçalhos são ignorados pelo Cloud Storage se estiverem definidos para evitar conteúdo em cache.

Operações atómicas

O Cloud Storage oferece garantias de atomicidade para a maioria das operações que envolvem objetos individuais, como carregar um objeto, atualizar os metadados de um objeto, substituir um objeto e eliminar um objeto.

Os pedidos em lote, que agregam operações individuais num único pedido, não são atómicos, porque é possível que algumas das operações contidas no lote falhem enquanto outras têm êxito.

A colocação em cache pode fazer com que receba versões desatualizadas de um objeto e, se fizer leituras por intervalo sem especificar um número de geração, os seus dados podem ficar danificados se o objeto for substituído entre leituras por intervalo sucessivas. Como prática recomendada, use pré-condições para se certificar de que está a obter a versão correta do objeto.

O que se segue?