Strategia relativa ai nuovi tentativi

In questa pagina viene descritto in che modo gli strumenti di Cloud Storage riprovano le richieste non riuscite. e come personalizzare il comportamento dei nuovi tentativi. Descrive inoltre e considerazioni per ritentare le richieste.

Panoramica

Esistono due fattori che determinano se è sicuro eseguire un nuovo tentativo di una richiesta:

1. La risposta che ricevi dalla richiesta.
2. L'idempotenza della richiesta.

Risposta

La risposta che ricevi indica se si tratta o meno di utile per ritentare la richiesta. Le risposte relative ai problemi temporanei vengono di solito ripetibili. Invece, le risposte relative agli errori permanenti. indicare che devi apportare modifiche, ad esempio all'autorizzazione o alla configurazione, modifiche, prima che sia utile riprovare la richiesta. Le seguenti risposte indicano problemi temporanei che è utile riprovare:

• Codici di risposta HTTP 408, 429 e 5xx.
• Timeout del socket e disconnessioni TCP.

Per ulteriori informazioni, controlla i codici di stato e di errore per JSON e XML.

Idempotenza

Una richiesta idempotente significa che può essere eseguita ripetutamente e sempre e lascia la risorsa target nello stesso stato finale. Ad esempio, scheda sono sempre idempotenti, perché non modificano le risorse. D'altra parte, creare una nuova notifica Pub/Sub non è mai idempotente, perché crea un nuovo ID notifica ogni volta che la richiesta ha esito positivo.

Di seguito sono riportati alcuni esempi di condizioni che rendono idempotente un'operazione:

• L'operazione ha lo stesso effetto osservabile sulla risorsa scelta come target quando richiesto continuamente.

• L'operazione riesce una sola volta.

• L'operazione non ha alcun effetto osservabile sullo stato della risorsa target.

Quando ricevi una risposta che può essere riprovata, devi considerare l'idempotenza della richiesta, perché ritentare richieste non idempotenti può portare sulle condizioni di gara e altri conflitti.

IDempotenza condizionale

Un sottoinsieme di richieste è condizionatamente idempotente, il che significa che vengono idempotenti se includono argomenti facoltativi specifici. Operazioni che sono Un nuovo tentativo sicuro in base alle condizioni deve essere ripetuto per impostazione predefinita solo se la condizione non supera la richiesta di assistenza. Cloud Storage accetta precondizioni ed ETag come le richieste di condizioni per le richieste.

Idempotenza delle operazioni

La tabella seguente elenca le operazioni di Cloud Storage che rientrano in ogni categoria di idempotenza.

Idempotenza	Operazioni
Sempre idempotente	Tutte le richieste get ed list Inserisci o elimina bucket Testa criteri e autorizzazioni IAM del bucket Blocca i criteri di conservazione Elimina una chiave HMAC o una notifica Pub/Sub
IDempotente condizionale	Richieste di aggiornamento/applicazione di patch per i bucket con IfMetagenerationMatch^1 o etag^1 come precondizione HTTP Richieste di aggiornamento/applicazione di patch per gli oggetti con IfMetagenerationMatch^1 o etag^1 come precondizione HTTP Imposta un criterio IAM del bucket con etag^1 come precondizione HTTP o nel corpo della risorsa Aggiorna una chiave HMAC con etag^1 come precondizione HTTP o nel corpo della risorsa Inserisci, copia, componi o riscrivi oggetti con ifGenerationMatch^1 Elimina un oggetto con ifGenerationMatch^1 (o con un numero di generazione per le versioni dell'oggetto)
Mai idempotente	Creare una chiave HMAC Crea una notifica Pub/Sub Crea, elimina o invia richieste di patch/aggiornamento per ACL di bucket e oggetti oppure ACL di oggetti predefiniti

¹ Questo campo può essere utilizzato nell'API JSON. Per i campi disponibili per l'uso nelle librerie client, consulta i documentazione relativa alla libreria client.

In che modo gli strumenti di Cloud Storage implementano le strategie di ripetizione

Console

La console Google Cloud invia richieste a Cloud Storage sul tuo e gestisce qualsiasi backoff necessario.

Riga di comando

Comandi gcloud storage riprovano a eseguire gli errori elencati in nella sezione Risposta senza che tu debba intraprendere altre azioni. Potresti dover intervenire per altri errori, ad esempio:

• Credenziali non valide o autorizzazioni insufficienti.

• Rete non raggiungibile a causa di un problema di configurazione del proxy.

In caso di errori ripetibili, gcloud CLI ripete le richieste utilizzando un strategia di backoff esponenziale binario troncato. Il valore predefinito il numero massimo di nuovi tentativi è 32 per gcloud CLI.

Librerie client

C++

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti codici di errore HTTP: nonché eventuali errori socket che indicano che la connessione è stata interrotta o e non è mai stato stabilito correttamente.

• 408 Request Timeout
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Tutte le impostazioni di backoff esponenziale e di nuovo tentativo nella libreria C++ vengono configurabile. Se gli algoritmi implementati nella libreria non supportano in base alle tue esigenze, puoi fornire codice personalizzato per implementare le tue strategie.

Impostazione	Valore predefinito
Nuovo tentativo automatico	Vero
Tempo massimo per i nuovi tentativi di una richiesta	15 minuti
Tempo di attesa iniziale (backoff)	1 secondo
Moltiplicatore del tempo di attesa per iterazione	2
Quantità massima di tempo di attesa	5 minuti

Per impostazione predefinita, la libreria C++ proverà nuovamente a eseguire tutte le operazioni con possibilità anche quelli che non sono mai idempotenti e che possono eliminare o creare più risorse in caso di esito positivo ripetuto. Per riprovare solo idempotenti operazioni, usa l'google::cloud::storage::StrictIdempotencyPolicy .

C#

La libreria client C# utilizza il backoff esponenziale per impostazione predefinita.

Vai

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti errori:

• Errori di connessione:
  • io.ErrUnexpectedEOF: questa situazione può essere dovuta a: problemi di rete temporanei.
  • url.Error contenente connection refused: questa a causa di problemi di rete temporanei.
  • url.Error contenente connection reset by peer: Ciò significa che Google Cloud ha reimpostato la connessione.
  • net.ErrClosed: indica che Google Cloud ha ha chiuso la connessione.
• Codici HTTP:
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
• Errori che implementano l'interfaccia Temporary() e assegnano un valore di err.Temporary() == true
• Uno qualsiasi degli errori riportati sopra che è stato aggregato utilizzando wrapping degli errori Go 1.13

Tutte le impostazioni di backoff esponenziale nella libreria Go sono configurabili. Per impostazione predefinita, le operazioni in Go utilizzano le seguenti impostazioni per backoff esponenziale (i valori predefiniti sono presi da gax):

Impostazione	Valore predefinito (in secondi)
Nuovo tentativo automatico	True se idempotente
Numero massimo di tentativi	Nessun limite
Ritardo tentativo iniziale	1 secondo
Moltiplicatore per ritardo nuovi tentativi	2.0
Ritardo massimo nuovi tentativi	30 secondi
Timeout totale (chunk di caricamento ripristinabile)	32 secondi
Timeout totale (tutte le altre operazioni)	Nessun limite

In generale, il nuovo tentativo continua a tempo indeterminato a meno che il valore di controllo contesto viene annullato, il client è chiuso oppure viene generato un errore non temporaneo ricevuto. Per impedire che i nuovi tentativi continuino, utilizza il timeout del contesto o l'annullamento. L'unica eccezione a questo comportamento si verifica quando si esegue di caricamenti ripristinabili utilizzando Writer, in cui i dati vengono abbastanza grande da richiedere più richieste. In questo scenario, ogni per impostazione predefinita il chunk si verifica in timeout e smette di riprovare dopo 32 secondi. Puoi regola il timeout predefinito modificando Writer.ChunkRetryDeadline.

Esiste un sottoinsieme di operazioni Go condizionalmente idempotente (condizionalmente sicuro, se puoi riprovare). Queste operazioni ritentano solo se soddisfano determinate condizioni:

• GenerationMatch o Generation

  • Riprovare se è stata applicata una precondizione GenerationMatch al o se è stato impostato ObjectHandle.Generation.

• MetagenerationMatch

  • Riprovare se è stata applicata una precondizione MetagenerationMatch alla chiamata.

• Etag

  • Riprova se il metodo inserisce un etag nella richiesta JSON del testo. Utilizzato solo in HMACKeyHandle.Update quando HmacKeyMetadata.Etag impostato.

RetryPolicy è impostato su RetryPolicy.RetryIdempotent per impostazione predefinita. Consulta: Personalizza i nuovi tentativi per trovare esempi su come modificare il nuovo tentativo predefinito. comportamento degli utenti.

Java

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti errori:

• Errori di connessione:
  • Connection reset by peer: indica che Google Cloud è stato reimpostato la connessione.
  • Unexpected connection closure: significa che Google Cloud ha chiuso la connessione.
• Codici HTTP:
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Tutte le impostazioni di backoff esponenziale nella libreria Java sono configurabili. Di per impostazione predefinita, le operazioni mediante Java utilizzano le seguenti impostazioni per backoff esponenziale:

Impostazione	Valore predefinito (in secondi)
Nuovo tentativo automatico	True se idempotente
Numero massimo di tentativi	6
Ritardo tentativo iniziale	1 secondo
Moltiplicatore per ritardo nuovi tentativi	2.0
Ritardo massimo nuovi tentativi	32 secondi
Timeout totale	50 secondi
Timeout RPC iniziale	50 secondi
Moltiplicatore timeout RPC	1,0
Timeout RPC massimo	50 secondi
Timeout connessione	20 secondi
Timeout lettura	20 secondi

Per ulteriori informazioni sulle impostazioni, consulta la documentazione di riferimento di Java documentazione per RetrySettings.Builder e HttpTransportOptions.Builder.

Esiste un sottoinsieme di operazioni Java idempotente condizionalmente (condizionatamente sicuro si può riprovare). Queste operazioni riprova solo se includono argomenti specifici:

• ifGenerationMatch o generation

  • Riprova se è stato superato ifGenerationMatch o generation come opzione per il metodo.

• ifMetagenerationMatch

  • Riprova se è stato passato ifMetagenerationMatch come opzione.

Il valore di StorageOptions.setStorageRetryStrategy è impostato su StorageRetryStrategy#getDefaultStorageRetryStrategy per impostazione predefinita. Consulta Personalizzare i nuovi tentativi per avere esempi su come modificare le impostazioni predefinite e riprova.

Node.js

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti codici di errore:

• Errori di connessione:
  • EAI_again: questo è un errore di ricerca DNS. Per ulteriori informazioni, vedi la documentazione di getaddrinfo.
  • Connection reset by peer: indica che Google Cloud è stato reimpostato la connessione.
  • Unexpected connection closure: significa che Google Cloud ha chiuso la connessione.
• Codici HTTP:
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Tutte le impostazioni di backoff esponenziale nella libreria Node.js sono configurabili. Per impostazione predefinita, le operazioni tramite Node.js usano le seguenti impostazioni per backoff esponenziale:

Impostazione	Valore predefinito (in secondi)
Nuovo tentativo automatico	True se idempotente
Numero massimo di nuovi tentativi	3
Tempo di attesa iniziale	1 secondo
Moltiplicatore del tempo di attesa per iterazione	2
Quantità massima di tempo di attesa	64 secondi
Scadenza predefinita	600 secondi

Esiste un sottoinsieme di operazioni Node.js con condizioni idempotente (condizionalmente sicuro, se puoi riprovare). Queste operazioni ritentano solo se includono argomenti specifici:

• ifGenerationMatch o generation

  • Riprova se è stato superato ifGenerationMatch o generation come opzione per il metodo. Spesso, i metodi accettano solo uno di questi due parametri.

• ifMetagenerationMatch

  • Riprova se è stato passato ifMetagenerationMatch come opzione.

Il valore di retryOptions.idempotencyStrategy è impostato su IdempotencyStrategy.RetryConditional per impostazione predefinita. Consulta: Personalizza i nuovi tentativi per trovare esempi su come modificare il nuovo tentativo predefinito. comportamento degli utenti.

PHP

La libreria client PHP utilizza il backoff esponenziale per impostazione predefinita.

Python

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti codici di errore:

• Errori di connessione:
  • requests.exceptions.ConnectionError
  • requests.exceptions.ChunkedEncodingError (solo per le operazioni recuperare o inviare dati payload agli oggetti, come caricamenti e download)
  • ConnectionError
• Codici HTTP:
  • 408 Request Timeout
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Le operazioni mediante Python usano le seguenti impostazioni predefinite per backoff esponenziale:

Impostazione	Valore predefinito (in secondi)
Nuovo tentativo automatico	True se idempotente
Tempo di attesa iniziale	1
Moltiplicatore del tempo di attesa per iterazione	2
Quantità massima di tempo di attesa	60
Scadenza predefinita	120

Esiste un sottoinsieme di operazioni Python condizionalmente idempotenti (condizionalmente sicuri da riprovare) quando includono specifiche argomenti. Queste operazioni ritentano solo se si verifica una richiesta di condizione tessere:

• DEFAULT_RETRY_IF_GENERATION_SPECIFIED

  • Riprova se è stato superato generation o if_generation_match come argomento al metodo. Spesso i metodi accettano solo uno di questi due parametri.

• DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED

  • È possibile riprovare se if_metageneration_match è stato trasmesso come al metodo.

• DEFAULT_RETRY_IF_ETAG_IN_JSON

  • Riprova se il metodo inserisce un etag nella richiesta JSON del testo. Per HMACKeyMetadata.update(), questo significa che l'etag deve essere impostato su l'oggetto HMACKeyMetadata stesso. Per set_iam_policy() su altre classi, significa che l'etag deve essere impostato nel "norme" passato nel metodo.

Ruby

Per impostazione predefinita, le operazioni supportano i nuovi tentativi per i seguenti codici di errore:

• Errori di connessione:
  • SocketError
  • HTTPClient::TimeoutError
  • Errno::ECONNREFUSED
  • HTTPClient::KeepAliveDisconnected
• Codici HTTP:
  • 408 Request Timeout
  • 429 Too Many Requests
  • 5xx Server Error

Tutte le impostazioni di backoff esponenziale nella libreria client Ruby sono configurabile. Per impostazione predefinita, le operazioni tramite la libreria client Ruby utilizzano le seguenti impostazioni per il backoff esponenziale:

Impostazione	Valore predefinito
Nuovo tentativo automatico	Vero
Numero massimo di nuovi tentativi	3
Tempo di attesa iniziale	1 secondo
Moltiplicatore del tempo di attesa per iterazione	2
Quantità massima di tempo di attesa	60 secondi
Scadenza predefinita	900 secondi

Esiste un sottoinsieme di operazioni Ruby con condizioni idempotenti (condizionalmente sicuri da riprovare) quando includono specifiche argomenti:

• if_generation_match o generation

  • È possibile riprovare se il parametro generation o if_generation_match viene passato come argomento al metodo. Spesso i metodi accettano solo uno di questi due parametri.

• if_metageneration_match

  • È possibile riprovare se il parametro if_metageneration_match viene passato come opzione.

Per impostazione predefinita, vengono ritentati tutte le operazioni idempotenti e in modo condizionale le operazioni idempotenti vengono ritentate solo se viene rispettata la condizione caso. Le operazioni non idempotenti non vengono tentate di nuovo. Vedi Personalizzare i nuovi tentativi. per vedere degli esempi su come modificare il comportamento predefinito per i nuovi tentativi.

API REST

Quando chiami direttamente l'API JSON o XML, devi utilizzare il metodo l'algoritmo di backoff esponenziale per implementare la tua strategia di ripetizione.

Personalizzazione dei nuovi tentativi

Console

Non puoi personalizzare il comportamento dei nuovi tentativi utilizzando la console Google Cloud.

Riga di comando

Per i comandi gcloud storage, puoi controllare la strategia per i nuovi tentativi creando una configurazione con nome e impostando alcune o tutte le seguenti proprietà:

• base_retry_delay
• exponential_sleep_multiplier
• max_retries
• max_retry_delay

Puoi quindi applicare la configurazione definita per ogni comando, usando il flag a livello di progetto --configuration o per tutti gli strumenti utilizzando il comando gcloud config set.

Librerie client

C++

Per personalizzare il comportamento dei nuovi tentativi, fornisci valori per le seguenti opzioni quando inizializza l'oggetto google::cloud::storage::Client:

• google::cloud::storage::RetryPolicyOption: la raccolta fornisce google::cloud::storage::LimitedErrorCountRetryPolicy e google::cloud::storage::LimitedTimeRetryPolicy corsi. Puoi fornire la propria classe, che deve implementare interfaccia di google::cloud::RetryPolicy.

• google::cloud::storage::BackoffPolicyOption: la raccolta fornisce la classe google::cloud::storage::ExponentialBackoffPolicy. Puoi fornire la propria classe, che deve implementare interfaccia di google::cloud::storage::BackoffPolicy.

• google::cloud::storage::IdempotencyPolicyOption: la raccolta fornisce i google::cloud::storage::StrictIdempotencyPolicy e google::cloud::storage::AlwaysRetryIdempotencyPolicy corsi. Tu puoi fornire la tua classe, che deve implementare interfaccia di google::cloud::storage::IdempotencyPolicy.

Per ulteriori informazioni, consulta la documentazione di riferimento della libreria client C++.

namespace gcs = ::google::cloud::storage;
// Create the client configuration:
auto options = google::cloud::Options{};
// Retries only idempotent operations.
options.set<gcs::IdempotencyPolicyOption>(
    gcs::StrictIdempotencyPolicy().clone());
// On error, it backs off for a random delay between [1, 3] seconds, then [3,
// 9] seconds, then [9, 27] seconds, etc. The backoff time never grows larger
// than 1 minute.
options.set<gcs::BackoffPolicyOption>(
    gcs::ExponentialBackoffPolicy(
        /*initial_delay=*/std::chrono::seconds(1),
        /*maximum_delay=*/std::chrono::minutes(1),
        /*scaling=*/3.0)
        .clone());
// Retries all operations for up to 5 minutes, including any backoff time.
options.set<gcs::RetryPolicyOption>(
    gcs::LimitedTimeRetryPolicy(std::chrono::minutes(5)).clone());
return gcs::Client(std::move(options));

C#

Non puoi personalizzare la strategia predefinita per i nuovi tentativi utilizzata libreria client C#.

Vai

Quando inizializzi un client di archiviazione, verrà eseguita una configurazione predefinita per i nuovi tentativi da impostare. A meno che non vengano sostituite, le opzioni nella configurazione siano impostati sui valori predefiniti. Gli utenti possono configurare un comportamento non predefinito dei nuovi tentativi per una singola chiamata alla libreria (utilizzando BucketHandle.Retryer e ObjectHandle.Retryer) o per tutti chiamate effettuate da un client (utilizzando Client.SetRetry). Per modificare un nuovo tentativo del comportamento, passa il valore RetryOptions pertinente a uno di questi metodi. di machine learning.

Guarda l'esempio di codice riportato di seguito per scoprire come personalizzare un nuovo tentativo comportamento degli utenti.

import (
	"context"
	"fmt"
	"io"
	"time"

	"cloud.google.com/go/storage"
	"github.com/googleapis/gax-go/v2"
)

// configureRetries configures a custom retry strategy for a single API call.
func configureRetries(w io.Writer, bucket, object string) error {
	// bucket := "bucket-name"
	// object := "object-name"
	ctx := context.Background()
	client, err := storage.NewClient(ctx)
	if err != nil {
		return fmt.Errorf("storage.NewClient: %w", err)
	}
	defer client.Close()

	// Configure retries for all operations using this ObjectHandle. Retries may
	// also be configured on the BucketHandle or Client types.
	o := client.Bucket(bucket).Object(object).Retryer(
		// Use WithBackoff to control the timing of the exponential backoff.
		storage.WithBackoff(gax.Backoff{
			// Set the initial retry delay to a maximum of 2 seconds. The length of
			// pauses between retries is subject to random jitter.
			Initial: 2 * time.Second,
			// Set the maximum retry delay to 60 seconds.
			Max: 60 * time.Second,
			// Set the backoff multiplier to 3.0.
			Multiplier: 3,
		}),
		// Use WithPolicy to customize retry so that all requests are retried even
		// if they are non-idempotent.
		storage.WithPolicy(storage.RetryAlways),
	)

	// Use context timeouts to set an overall deadline on the call, including all
	// potential retries.
	ctx, cancel := context.WithTimeout(ctx, 500*time.Second)
	defer cancel()

	// Delete an object using the specified retry policy.
	if err := o.Delete(ctx); err != nil {
		return fmt.Errorf("Object(%q).Delete: %w", object, err)
	}
	fmt.Fprintf(w, "Blob %v deleted with a customized retry strategy.\n", object)
	return nil
}

Java

Quando si inizializza Storage, viene generata un'istanza di Anche RetrySettings è stato inizializzato. A meno che non siano con override, le opzioni in RetrySettings sono impostate sul valori predefiniti. Per modificare il comportamento predefinito per i nuovi tentativi automatici, supera lo StorageRetryStrategy personalizzato nella StorageOptions usata per creare l'istanza Storage. Per modificare qualsiasi altro modello scalare, parametri, passa un valore RetrySettings personalizzato al valore StorageOptions utilizzato per creare l'istanza Storage.

Consulta l'esempio seguente per scoprire come personalizzare il comportamento dei nuovi tentativi:

import com.google.api.gax.retrying.RetrySettings;
import com.google.cloud.storage.BlobId;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;
import com.google.cloud.storage.StorageRetryStrategy;
import org.threeten.bp.Duration;

public final class ConfigureRetries {
  public static void main(String[] args) {
    String bucketName = "my-bucket";
    String blobName = "blob/to/delete";
    deleteBlob(bucketName, blobName);
  }

  static void deleteBlob(String bucketName, String blobName) {
    // Customize retry behavior
    RetrySettings retrySettings =
        StorageOptions.getDefaultRetrySettings()
            .toBuilder()
            // Set the max number of attempts to 10 (initial attempt plus 9 retries)
            .setMaxAttempts(10)
            // Set the backoff multiplier to 3.0
            .setRetryDelayMultiplier(3.0)
            // Set the max duration of all attempts to 5 minutes
            .setTotalTimeout(Duration.ofMinutes(5))
            .build();

    StorageOptions alwaysRetryStorageOptions =
        StorageOptions.newBuilder()
            // Customize retry so all requests are retried even if they are non-idempotent.
            .setStorageRetryStrategy(StorageRetryStrategy.getUniformStorageRetryStrategy())
            // provide the previously configured retrySettings
            .setRetrySettings(retrySettings)
            .build();

    // Instantiate a client
    Storage storage = alwaysRetryStorageOptions.getService();

    // Delete the blob
    BlobId blobId = BlobId.of(bucketName, blobName);
    boolean success = storage.delete(blobId);

    System.out.printf(
        "Deletion of Blob %s completed %s.%n", blobId, success ? "successfully" : "unsuccessfully");
  }
}

Node.js

Quando inizializza Cloud Storage, viene eseguita una configurazione viene inizializzato anche il file. A meno che non vengano sostituite, le opzioni nella configurazione siano impostati sui valori predefiniti. Per modificare comportamento predefinito per i nuovi tentativi, passa la configurazione personalizzata dei nuovi tentativi retryOptions nel costruttore di archiviazione al momento dell'inizializzazione. La libreria client Node.js può utilizzare automaticamente le strategie di backoff per con il parametro autoRetry.

Guarda l'esempio di codice riportato di seguito per scoprire come personalizzare un nuovo tentativo comportamento degli utenti.

/**
 * TODO(developer): Uncomment the following lines before running the sample.
 */
// The ID of your GCS bucket
// const bucketName = 'your-unique-bucket-name';

// The ID of your GCS file
// const fileName = 'your-file-name';

// Imports the Google Cloud client library
const {Storage} = require('@google-cloud/storage');

// Creates a client
const storage = new Storage({
  retryOptions: {
    // If this is false, requests will not retry and the parameters
    // below will not affect retry behavior.
    autoRetry: true,
    // The multiplier by which to increase the delay time between the
    // completion of failed requests, and the initiation of the subsequent
    // retrying request.
    retryDelayMultiplier: 3,
    // The total time between an initial request getting sent and its timeout.
    // After timeout, an error will be returned regardless of any retry attempts
    // made during this time period.
    totalTimeout: 500,
    // The maximum delay time between requests. When this value is reached,
    // retryDelayMultiplier will no longer be used to increase delay time.
    maxRetryDelay: 60,
    // The maximum number of automatic retries attempted before returning
    // the error.
    maxRetries: 5,
    // Will respect other retry settings and attempt to always retry
    // conditionally idempotent operations, regardless of precondition
    idempotencyStrategy: IdempotencyStrategy.RetryAlways,
  },
});
console.log(
  'Functions are customized to be retried according to the following parameters:'
);
console.log(`Auto Retry: ${storage.retryOptions.autoRetry}`);
console.log(
  `Retry delay multiplier: ${storage.retryOptions.retryDelayMultiplier}`
);
console.log(`Total timeout: ${storage.retryOptions.totalTimeout}`);
console.log(`Maximum retry delay: ${storage.retryOptions.maxRetryDelay}`);
console.log(`Maximum retries: ${storage.retryOptions.maxRetries}`);
console.log(
  `Idempotency strategy: ${storage.retryOptions.idempotencyStrategy}`
);

async function deleteFileWithCustomizedRetrySetting() {
  await storage.bucket(bucketName).file(fileName).delete();
  console.log(`File ${fileName} deleted with a customized retry strategy.`);
}

deleteFileWithCustomizedRetrySetting();

PHP

Non puoi personalizzare la strategia predefinita per i nuovi tentativi utilizzata con la libreria client PHP.

Python

Per modificare il comportamento predefinito per i nuovi tentativi, crea una copia del google.cloud.storage.retry.DEFAULT_RETRY oggetto chiamandolo con un Metodo with_XXX. La libreria client Python utilizza automaticamente il backoff strategie per ritentare le richieste se includi DEFAULT_RETRY .

Tieni presente che with_predicate non è supportato per le operazioni che recuperano o inviano dati payload agli oggetti, come caricamenti e download. È consigliamo di modificare gli attributi uno alla volta. Per ulteriori informazioni, consulta il riferimento google-api-core Riprova.

Per configurare un nuovo tentativo condizionale, crea un ConditionalRetryPolicy e aggregare l'oggetto Retry personalizzato oggetto con DEFAULT_RETRY_IF_GENERATION_SPECIFIED, DEFAULT_RETRY_IF_METAGENERATION_SPECIFIED oppure DEFAULT_RETRY_IF_ETAG_IN_JSON.

Guarda l'esempio di codice riportato di seguito per scoprire come personalizzare un nuovo tentativo comportamento degli utenti.

from google.cloud import storage
from google.cloud.storage.retry import DEFAULT_RETRY


def configure_retries(bucket_name, blob_name):
    """Configures retries with customizations."""
    # The ID of your GCS bucket
    # bucket_name = "your-bucket-name"
    # The ID of your GCS object
    # blob_name = "your-object-name"

    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(blob_name)

    # Customize retry with a deadline of 500 seconds (default=120 seconds).
    modified_retry = DEFAULT_RETRY.with_deadline(500.0)
    # Customize retry with an initial wait time of 1.5 (default=1.0).
    # Customize retry with a wait time multiplier per iteration of 1.2 (default=2.0).
    # Customize retry with a maximum wait time of 45.0 (default=60.0).
    modified_retry = modified_retry.with_delay(initial=1.5, multiplier=1.2, maximum=45.0)

    # blob.delete() uses DEFAULT_RETRY_IF_GENERATION_SPECIFIED by default.
    # Override with modified_retry so the function retries even if the generation
    # number is not specified.
    print(
        f"The following library method is customized to be retried according to the following configurations: {modified_retry}"
    )

    blob.delete(retry=modified_retry)
    print(f"Blob {blob_name} deleted with a customized retry strategy.")

Ruby

Quando inizializza il client di archiviazione, vengono impostate tutte le configurazioni dei nuovi tentativi ai valori mostrati nella tabella precedente. Per modificare il nuovo tentativo predefinito , passare le configurazioni dei nuovi tentativi durante l'inizializzazione del client di archiviazione.

Per sostituire il numero di nuovi tentativi per una determinata operazione, supera retries nel parametro options dell'operazione.

def configure_retries bucket_name: nil, file_name: nil
  # The ID of your GCS bucket
  # bucket_name = "your-unique-bucket-name"

  # The ID of your GCS object
  # file_name = "your-file-name"

  require "google/cloud/storage"

  # Creates a client
  storage = Google::Cloud::Storage.new(

    # The maximum number of automatic retries attempted before returning
    # the error.
    #
    # Customize retry configuration with the maximum retry attempt of 5.
    retries: 5,

    # The total time in seconds that requests are allowed to keep being retried.
    # After max_elapsed_time, an error will be returned regardless of any
    # retry attempts made during this time period.
    #
    # Customize retry configuration with maximum elapsed time of 500 seconds.
    max_elapsed_time: 500,

    # The initial interval between the completion of failed requests, and the
    # initiation of the subsequent retrying request.
    #
    # Customize retry configuration with an initial interval of 1.5 seconds.
    base_interval: 1.5,

    # The maximum interval between requests. When this value is reached,
    # multiplier will no longer be used to increase the interval.
    #
    # Customize retry configuration with maximum interval of 45.0 seconds.
    max_interval: 45,

    # The multiplier by which to increase the interval between the completion
    # of failed requests, and the initiation of the subsequent retrying request.
    #
    # Customize retry configuration with an interval multiplier per iteration of 1.2.
    multiplier: 1.2
  )

  # Uses the retry configuration set during the client initialization above with 5 retries
  file = storage.service.get_file bucket_name, file_name

  # Maximum retry attempt can be overridden for each operation using options parameter.
  storage.service.delete_file bucket_name, file_name, options: { retries: 4 }
  puts "File #{file.name} deleted with a customized retry strategy."
end

API REST

Utilizza l'algoritmo di backoff esponenziale per implementare il tuo nuovo tentativo strategia.

Algoritmo di backoff esponenziale

Un algoritmo di backoff esponenziale riprova le richieste utilizzando aumentando in modo esponenziale i tempi di attesa tra le richieste, fino a un il tempo di backoff. In genere dovresti utilizzare il backoff esponenziale con il jitter per nuove richieste che soddisfino sia i criteri di risposta sia i criteri di idempotenza. Per il meglio che implementano i nuovi tentativi automatici con backoff esponenziale, consulta Gestire gli errori a cascata.

Passaggi successivi

• Scopri come ritentare le richieste in Storage Transfer Service con in Java o Python.
• Scopri di più sulle condizioni preliminari per richiedere.