Repetir eventos

Um evento pode ser rejeitado por vários motivos. Por exemplo, o serviço de receção de eventos pode estar temporariamente indisponível devido a uma falha; o serviço pode encontrar um erro ao processar um evento; ou os recursos do serviço podem ficar esgotados. Os erros temporários, como este, podem ser repetidos.

Um evento também pode não ser entregue ao destinatário do evento. Por exemplo, o evento pode não corresponder ao esquema esperado configurado ou a mediação do evento pode falhar antes de a mensagem do evento poder ser encaminhada para o respetivo destino final. Estes casos resultam em erros persistentes.

Erros temporários

O Eventarc Advanced oferece-lhe a capacidade de processar erros transitórios. Pode tentar novamente estes erros temporários, que incluem os seguintes códigos de erro:

  • HTTP 408 Request Timeout
  • HTTP 409 Conflict
  • HTTP 429 Too Many Requests
  • HTTP 500 Internal Server Error
  • HTTP 502 Bad Gateway
  • HTTP 503 Service Unavailable
  • HTTP 504 Gateway Time-out

Erros persistentes

Ao contrário dos erros temporários, os erros persistentes incluem o seguinte:

  • Erros que ocorrem quando o número de novas tentativas configuradas se esgota
  • Erros que ocorrem quando um evento falha antes de poder ser encaminhado para o respetivo destino
  • Erros que resultam num código de erro considerado não repetível; por exemplo, códigos de erro que não sejam os indicados para erros transitórios

Pode identificar manualmente erros persistentes e processá-los adequadamente.

Volte a tentar erros temporários

O Eventarc Advanced usa um atraso de retirada exponencial para processar erros que podem ser repetidos. A política de novas tentativas predefinida começa com um atraso de um segundo e o atraso é duplicado após cada tentativa falhada (até um máximo de 60 segundos e cinco tentativas).

Pode alterar a política de repetição predefinida através da consola ou do comando gcloud eventarc pipelines update. Google Cloud

Tenha em atenção que não é possível alterar o fator de recuo predefinido de 2.

Consola

  1. Na Google Cloud consola, aceda à página Eventarc > Pipelines.

    Aceda a Pipelines

  2. Clique no nome do pipeline.

  3. Na página Detalhes do pipeline, clique em Editar.

  4. Na página Editar pipeline, na secção Política de repetição, modifique os seguintes campos:

    • Máximo de tentativas: o número de novas tentativas; o valor predefinido é de 5 tentativas. Pode ser qualquer número real positivo. Se estiver definido como 1, não é aplicada nenhuma política de repetição e é feita apenas uma tentativa de entregar uma mensagem.
    • Atraso mínimo (segundos): o atraso inicial em segundos; a predefinição é de 1 segundos. Tem de ser um valor entre 1 e 600.
    • Atraso máximo (segundos): o atraso máximo em segundos; a predefinição é de 60 segundos. Tem de ser um valor entre 1 e 600.

    Pode configurar um recuo linear definindo os atrasos mínimos e máximos com o mesmo valor.

  5. Clique em Guardar.

gcloud 

gcloud eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

Substitua o seguinte:

  • PIPELINE_NAME: o ID ou o identificador totalmente qualificado da pipeline.
  • MIN_DELAY: o atraso inicial em segundos; o valor predefinido é 1 segundo. Tem de ser um valor entre 1 e 600.
  • MAX_DELAY: o atraso máximo em segundos; o valor predefinido é 60 segundos. Tem de ser um valor entre 1 e 600.
  • MAX_ATTEMPTS: o número de novas tentativas; a predefinição é de 5 tentativas. Pode ser qualquer número real positivo. Se estiver definido como 1, não é aplicada nenhuma política de repetição e é feita apenas uma tentativa de enviar uma mensagem.

O exemplo seguinte configura um recuo linear definindo os atrasos mínimo e máximo para o mesmo valor:

gcloud eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Arquive mensagens para resolver erros persistentes

Pode escrever mensagens numa tabela do BigQuery à medida que são recebidas. Isto permite-lhe identificar manualmente erros persistentes e processá-los adequadamente.

Segue-se uma vista geral dos passos necessários para arquivar as mensagens de eventos, identificar erros persistentes e tentar novamente os eventos afetados.

  1. Crie um autocarro. Configurar o barramento adequadamente; por exemplo, para publicar eventos de origens Google.
  2. Crie um tópico do Pub/Sub. Este tópico do Pub/Sub vai ser o destino da sua pipeline.
  3. Crie uma subscrição do BigQuery para o tópico do Pub/Sub. Uma subscrição do BigQuery é um tipo de subscrição de exportação que escreve mensagens numa tabela do BigQuery existente à medida que são recebidas. Em alternativa, pode criar a tabela quando criar a subscrição do BigQuery.

  4. Crie um pipeline e uma inscrição que encaminhe todas as mensagens recebidas pelo barramento (através de --cel-match="true") para o tópico do Pub/Sub. Configure uma política de repetição para a conduta.

    Por exemplo, os comandos seguintes criam um pipeline e uma inscrição:

    gcloud eventarc pipelines create my-archive-pipeline \
    --destinations=pubsub_topic='my-archive-topic' \
    --min-retry-delay=1 \
    --max-retry-delay=20 \
    --max-retry-attempts=6 \
    --location=us-central1

    gcloud eventarc enrollments create my-archive-enrollment \
    --cel-match="true" \
    --destination-pipeline=my-archive-pipeline \
    --message-bus=my-message-bus \
    --message-bus-project=my-google-cloud-project \
    --location=us-central1

  5. Encaminhe os registos do pipeline para outro conjunto de dados do BigQuery.

    Agora, deve ter dois conjuntos de dados do BigQuery separados: um que armazena todas as mensagens recebidas pelo seu Eventarc Advanced bus e outro que armazena os registos do pipeline.

  6. Para identificar mensagens com falhas, use uma declaração de consulta para juntar ambos os conjuntos de dados do BigQuery no campo message_uid.

  7. Depois de identificar as mensagens com falhas, pode publicá-las novamente no seu barramento através da API Eventarc Publishing. Por exemplo, pode implementar um serviço ou uma tarefa do Cloud Run para ler as mensagens do BigQuery e publicá-las diretamente no barramento avançado do Eventarc.

Torne os controladores de eventos idempotentes

Os controladores de eventos que podem ser repetidos devem ser idempotentes, usando as seguintes diretrizes gerais:

  • Muitas APIs externas permitem-lhe fornecer uma chave de idempotência como parâmetro. Se estiver a usar uma API deste tipo, deve usar a origem e o ID do evento como a chave de idempotência. (Os produtores têm de garantir que source + id é exclusivo para cada evento distinto.)
  • Além disso, pode usar um atributo CloudEvents, xgooglemessageuid, para fornecer idempotência. O valor deste atributo é igual ao campo message_uid nas mensagens avançadas do Eventarc. Identifica de forma exclusiva a ação de publicar um evento. Por exemplo, se o mesmo evento for publicado duas vezes num barramento, cada evento terá um valor xgooglemessageuid diferente quando for enviado para um controlador de eventos.
  • A idempotência funciona bem com o fornecimento pelo menos uma vez, porque torna a repetição segura. Assim, uma prática recomendada geral para escrever código fiável é combinar a idempotência com as novas tentativas.
  • Certifique-se de que o seu código é idempotente internamente. Por exemplo:
    • Certifique-se de que as mutações podem ocorrer mais do que uma vez sem alterar o resultado.
    • Consultar o estado da base de dados numa transação antes de alterar o estado.
    • Certifique-se de que todos os efeitos secundários são idempotentes.
  • Imponha uma verificação transacional fora do seu serviço, independentemente do código. Por exemplo, manter o estado num local que registe que um determinado ID do evento já foi processado.
  • Lidar com chamadas duplicadas fora da banda. Por exemplo, ter um processo de limpeza separado que limpe após chamadas duplicadas.

O que se segue?