Jobs em background idempotentes
O curso mostra como escrever um job em background que pode rodar mais de uma vez sem causar dano, com o Partners::FetchSiteIconJob como exemplo ao longo das aulas. Ele compara a checagem feita no enfileiramento com a feita dentro do perform. Depois apresenta três ferramentas para um passo: conferir o estado, usar um índice único com create_or_find_by! e gravar estados absolutos. Um segundo passo hipotético mostra onde uma guarda só falha. Por fim, trata de reservas gravadas antes do efeito, da ordem dos passos e de GET contra POST com chave de deduplicação.
O que você vai aprender
- ✓Por que a guarda dentro do perform protege novas tentativas e a checagem no enfileiramento não
- ✓Três formas de tornar um passo seguro de refazer: checagem de estado, índice único e escrita absoluta
- ✓Como seguir cada ponto de queda entre dois efeitos de um job
- ✓Como proteger um passo com uma linha de reserva sob índice único, gravada antes do efeito
- ✓Por que deixar o passo menos seguro por último reduz o estrago de uma guarda que falta
- ✓A diferença entre GET e um POST externo que precisa de chave de deduplicação
Um guarda nunca foi o trabalho inteiro
Dois cursos já apontaram para cá pelo nome. O curso de nível Pleno "Padrão: chaves de idempotência" construiu uma guarda de reservar, trabalhar, concluir em volta de uma operação inteira, e fechou descrevendo este: "Aquele faz uma pergunta mais difícil: como projetar um job para ser seguro de…
Ler a aula completa grátis →Currículo
7 aulasUm guarda nunca foi o trabalho inteiro
Mostra como uma checagem de attached? torna o FetchSiteIconJob idempotente e por que a checagem dentro do perform importa.
Três formas de tornar um passo seguro para refazer
Apresenta conferir o estado antes de agir, deixar um índice único recusar duplicatas e gravar estados finais absolutos.
Um job com duas coisas para fazer
Acrescenta um passo hipotético de e-mail e segue cada ponto de queda até a guarda pular o segundo passo.
O passo que você não consegue guardar com uma checagem de estado
Protege o passo do e-mail com uma linha de reserva sob índice único, criada antes do efeito colateral.
Coloque o passo inseguro por último
Explica por que deixar o passo menos seguro por último troca um efeito duplicado por um efeito atrasado.
Idempotente pelas regras, e idempotente por acordo
Compara o GET, idempotente pela especificação HTTP, com o POST externo, que depende de uma chave combinada para deduplicar.
Juntando tudo: um job que pode morrer em qualquer lugar e ainda estar certo
Percorre o job completo passo a passo e mostra quais passos precisam de guarda e quais não precisam de nada.