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
  • Lecture après mise à jour des métadonnées
  • 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 (y compris le remplacement d'un objet existant), la mise à jour de ses métadonnées, le remplacement d'un objet et la suppression d'un objet.

Il n'est pas garanti que les requêtes par lot soient atomiques. Bien que les opérations individuelles d'une requête par lot puissent être atomiques, il n'est pas garanti que toutes les opérations de la requête par lot soient atomiques en tant que groupe, car il est possible que certaines d'entre elles réussissent tandis que d'autres échouent.

Dans certains cas, vous pouvez récupérer une version antérieure d'un objet, par exemple lorsque les données mises en cache deviennent obsolètes ou lorsque vous effectuez des lectures par plage sans spécifier de numéro de génération, auquel cas l'objet que vous souhaitez récupérer est écrasé. Nous vous recommandons d'utiliser des conditions préalables pour vous assurer de récupérer la bonne version de l'objet.

Étape suivante