Cohérence

Cette page décrit les opérations Cloud Storage qui sont fortement cohérentes et celles qui sont cohérentes à terme. Dans le cas d'objets lisibles publiquement et pouvant être mis en cache, vous pouvez contrôler le degré de cohérence des opérations exécutées sur les objets.

Opérations fortement cohérentes

Cloud Storage offre une cohérence globale forte pour les opérations suivantes :

  • Lecture après écriture
  • Read-after-metadata-update
  • Lecture après suppression
  • Affichage d'une liste de buckets
  • Répertorier des objets

Lorsque vous écrivez un objet dans Cloud Storage, par exemple lorsque vous importez, composez ou copiez un objet, celui-ci est immédiatement disponible pour les opérations de lecture et celles associées aux métadonnées, dès lors que vous recevez une réponse positive à votre requête d'écriture. Cela est valable pour tous les buckets et pour toutes les classes de stockage, et tant pour la création d'objets que pour le remplacement d'objets existants.

Comme les écritures sont fortement cohérentes, vous ne recevez jamais de réponse 404 Not Found ni de données obsolètes pour une opération de lecture après écriture ou de lecture après mise à jour des métadonnées, même pour les buckets situés dans des emplacements birégionaux ou multirégionaux. Dans les rares cas où vos données n'ont pas encore été répliquées dans plusieurs régions, mais où l'emplacement dans lequel votre objet a été écrit pour la première fois devient indisponible, les tentatives d'accès à l'objet renvoient une Réponse d'erreur 500 récupérable.

La cohérence globale forte s'étend également aux opérations de suppression d'objets. Si une requête de suppression aboutit, toute tentative immédiate de téléchargement de l'objet ou de ses métadonnées renvoie le code d'état 404 Not Found. L'erreur 404 est générée, car l'objet n'existe plus une fois l'opération de suppression exécutée.

La création de listes de buckets et d'objets est fortement cohérente : lorsque vous créez un bucket ou un objet, puis que vous exécutez immédiatement l'opération list appropriée, le bucket ou l'objet qui vient d'être créé apparaît dans la liste renvoyée.

Pour les buckets, alors que les mises à jour de métadonnées sont fortement cohérentes pour les opérations de lecture après mise à jour des métadonnées, la propagation des modifications de configuration qui en résultent peut prendre du temps. Par exemple, si vous activez la gestion des versions d'objets pour un bucket, vous devez attendre au moins 30 secondes pour que les objets soient supprimés ou remplacés.

De même, pour les clés HMAC, il faut compter jusqu'à trois minutes entre le moment où vous demandez la modification de l'état de la clé et son entrée en vigueur. Par exemple, si vous désactivez une clé HMAC, vous devez attendre au moins trois minutes avant de demander la suppression de la clé, car les tentatives effectuées dans les trois premières minutes peuvent échouer.

Opérations cohérentes à terme

Les opérations suivantes sont cohérentes à terme :

  • Accorder ou révoquer l'accès aux ressources

En règle générale, ces opérations prennent environ une minute. Dans certains cas, elles peuvent nécessiter quelques minutes de plus.

Pour illustrer le comportement pouvant résulter de la cohérence à terme, prenons l'exemple suivant : si vous supprimez l'accès d'un utilisateur à un bucket, cette modification est immédiatement reflétée dans les métadonnées du bucket. Toutefois, il est possible que l'utilisateur ait toujours accès au bucket pendant un court laps de temps.

Cohérence et contrôle du cache

Les objets mis en cache qui sont lisibles publiquement peuvent ne pas avoir une cohérence forte. Si vous autorisez la mise en cache d'un objet et si celui-ci se trouve dans le cache lors de sa mise à jour ou de sa suppression, il n'est ni mis à jour, ni supprimé tant que sa durée de vie dans le cache n'a pas expiré.

La durée de vie d'un objet dans le cache est déterminée par les métadonnées Cache-Control associées à l'objet. Vous pouvez définir les métadonnées Cache-Control à l'aide d'un en-tête de requête Cache-Control inclus dans l'importation initiale de l'objet ou dans une mise à jour ultérieure des métadonnées de l'objet. Étant donné que vous contrôlez les métadonnées Cache-Control, vous déterminez également le degré de cohérence des objets mis en cache. Les requêtes concernant l'objet peuvent inclure leur propre en-tête Cache-Control. Toutefois, Cloud Storage ignore ces en-têtes s'ils sont définis pour éviter la mise en cache de contenu.

Opérations atomiques

Cloud Storage assure des garanties d'atomicité pour la plupart des opérations impliquant des objets individuels, telles que l'importation d'un objet, la mise à jour de ses métadonnées et sa suppression. Les opérations impliquant plusieurs objets simultanément, telles que la copie ou le renommage de plusieurs objets, ne sont pas des opérations atomiques.

Étapes suivantes