Políticas de nova tentativa nas bibliotecas de cliente do C++

Esta página descreve o modelo de nova tentativa usado pelas bibliotecas de cliente do C++.

As bibliotecas de cliente emitem RPCs (chamadas de procedimento remoto) em seu nome. Essas RPCs podem falhar devido a erros temporários. Os servidores são reiniciados, os balanceadores de carga fecham conexões sobrecarregadas ou inativas, e os limites de taxa podem entrar em vigor. Esses são apenas alguns exemplos de falhas temporárias.

As bibliotecas podem retornar esses erros ao aplicativo. No entanto, muitos desses erros são fáceis de processar na biblioteca, o que simplifica o código do aplicativo.

Erros e operações que permitem novas tentativas

Somente erros temporários podem ser repetidos. Por exemplo, kUnavailable indica que o cliente não conseguiu se conectar ou perdeu a conexão com um serviço enquanto uma solicitação estava em andamento. Essa é quase sempre uma condição temporária, embora possa levar muito tempo para se recuperar. Esses erros sempre podem ser repetidos (supondo que a operação em si seja segura para repetir). Em contrato, os erros kPermissionDenied exigem intervenção adicional (geralmente humana) para serem resolvidos. Esses erros não são considerados "temporários" ou, pelo menos, não temporários nos períodos considerados pelos loops de repetição na biblioteca de cliente.

Da mesma forma, algumas operações não são seguras para repetir, independentemente da natureza do erro. Isso inclui todas as operações que fazem mudanças incrementais. Por exemplo, não é seguro repetir uma operação para remover "a versão mais recente de X" quando há várias versões de um recurso chamado "X". Isso ocorre porque o autor da chamada provavelmente pretendia remover uma única versão, e repetir essa solicitação pode resultar na remoção de todas as versões.

Configurar loops de repetição

As bibliotecas de cliente aceitam três parâmetros de configuração diferentes para controlar os loops de repetição:

  • O *IdempotencyPolicy determina se uma solicitação específica é idempotente. Somente essas solicitações são repetidas.
  • O *RetryPolicy determina (a) se um erro deve ser considerado uma falha temporária e (b) por quanto tempo (ou quantas vezes) a biblioteca de cliente repete uma solicitação.
  • O *BackoffPolicy determina por quanto tempo a biblioteca de cliente aguarda antes de reenviar a solicitação.

Política de idempotência padrão

Em geral, uma operação é idempotente se chamar a função várias vezes deixar o sistema no mesmo estado que chamar a função uma vez. Somente operações idempotentes são seguras para repetir. Exemplos de operações idempotentes incluem, entre outros, todas as operações somente leitura e operações que só podem ser bem-sucedidas uma vez.

Por padrão, a biblioteca de cliente só trata RPCs implementadas por verbos GET ou PUT como idempotentes. Isso pode ser muito conservador. Em alguns serviços, até mesmo algumas solicitações POST são idempotentes. Você sempre pode substituir a política de idempotência padrão para atender melhor às suas necessidades.

Algumas operações só são idempotentes se incluírem condições prévias. Por exemplo, "remover a versão mais recente se a versão mais recente for Y" é idempotente, porque só pode ser bem-sucedida uma vez.

Periodicamente, as bibliotecas de cliente recebem melhorias para tratar mais operações como idempotentes. Consideramos essas melhorias como correções de bugs e, portanto, não prejudiciais, mesmo que mudem o comportamento da biblioteca de cliente.

Embora possa ser seguro repetir uma operação, isso não significa que ela produz o mesmo resultado na segunda tentativa em comparação com a primeira tentativa bem-sucedida. Por exemplo, criar um recurso identificado de maneira exclusiva pode ser seguro para repetir, já que a segunda e as tentativas sucessivas falham e deixam o sistema no mesmo estado. No entanto, o cliente pode receber um erro "já existe" nas tentativas de repetição.

Política de repetição padrão

Seguindo as diretrizes descritas em aip/194, a maioria das bibliotecas de cliente do C++ só repete UNAVAILABLE erros do gRPC. Eles são mapeados para StatusCode::kUnavailable. A política padrão é repetir as solicitações por 30 minutos.

Os erros kUnavailable não indicam que o servidor não recebeu a solicitação. Esse código de erro é usado quando a solicitação não pode ser enviada, mas também é usado se a solicitação for enviada com sucesso, recebida pelo serviço e a conexão for perdida antes que a resposta seja recebida pelo cliente. Além disso, se você pudesse determinar se a solicitação foi recebida com sucesso, poderia resolver o problema dos dois generais, um resultado de impossibilidade bem conhecido em sistemas distribuídos.

Portanto, não é seguro repetir todas as operações que falham com kUnavailable. A idempotência da operação também é importante.

Política de espera padrão

Por padrão, a maioria das bibliotecas usa uma estratégia de espera exponencial truncada, com instabilidade. A espera inicial é de 1 segundo, a espera máxima é de 5 minutos e a espera dobra após cada repetição.

Mudar as políticas de repetição e espera padrão

Cada biblioteca define uma struct *Option para configurar essas políticas. Você pode fornecer essas opções ao criar a classe *Client ou até mesmo em cada solicitação.

Por exemplo, isso mostra como mudar as políticas de repetição e espera de um cliente do Cloud Pub/Sub:

namespace pubsub = ::google::cloud::pubsub;
using ::google::cloud::future;
using ::google::cloud::Options;
using ::google::cloud::StatusOr;
[](std::string project_id, std::string topic_id) {
  auto topic = pubsub::Topic(std::move(project_id), std::move(topic_id));
  // By default a publisher will retry for 60 seconds, with an initial backoff
  // of 100ms, a maximum backoff of 60 seconds, and the backoff will grow by
  // 30% after each attempt. This changes those defaults.
  auto publisher = pubsub::Publisher(pubsub::MakePublisherConnection(
      std::move(topic),
      Options{}
          .set<pubsub::RetryPolicyOption>(
              pubsub::LimitedTimeRetryPolicy(
                  /*maximum_duration=*/std::chrono::minutes(10))
                  .clone())
          .set<pubsub::BackoffPolicyOption>(
              pubsub::ExponentialBackoffPolicy(
                  /*initial_delay=*/std::chrono::milliseconds(200),
                  /*maximum_delay=*/std::chrono::seconds(45),
                  /*scaling=*/2.0)
                  .clone())));

  std::vector<future<bool>> done;
  for (char const* data : {"1", "2", "3", "go!"}) {
    done.push_back(
        publisher.Publish(pubsub::MessageBuilder().SetData(data).Build())
            .then([](future<StatusOr<std::string>> f) {
              return f.get().ok();
            }));
  }
  publisher.Flush();
  int count = 0;
  for (auto& f : done) {
    if (f.get()) ++count;
  }
  std::cout << count << " messages sent successfully\n";
}

Consulte a documentação de cada biblioteca para encontrar os nomes e exemplos específicos dela.

Próximas etapas