Arrefecimento num pool de proxies: rastreie falhas e verifique a recuperação
Dê ao pool de proxies estados temporários explícitos e um caminho de recuperação em vez de eliminar um endpoint após um único pedido lento.
Um proxy perde um prazo. O pool elimina-o. Uma hora depois o proxy está saudável de novo, mas a sua aplicação não tem forma de o descobrir porque deitou fora o registo.
Remover pode ser adequado para uma conta revogada ou um endpoint que o operador retirou. Uma falha transitória merece um estado diferente.
Guarde histórico suficiente para a próxima decisão
- Elegível
- Disponível para trabalho comum segundo a política atual.
- A arrefecer
- Retido temporariamente até um prazo registado.
- Sonda permitida
- Uma tentativa controlada pode avaliar a recuperação.
- Desativado
- Um operador ou uma condição duradoura removeu-o do serviço.
Guarde o motivo e a fase juntamente com a transição. Uma recusa de ligação, credenciais rejeitadas, um corpo de resposta lento e um erro HTTP no destino não devem todos incrementar um contador indiferenciado de «proxy morto».
Use um relógio de tempo decorrido para um arrefecimento dentro do processo. Um relógio monotónico evita que uma espera curta dependa de um ajuste do relógio de parede. Não persista um carimbo monotónico como se fosse uma data portátil partilhada por outras máquinas; um agendador distribuído precisa de um modelo de tempo e propriedade definido em separado.
A recuperação não deve libertar uma debandada
Quando o prazo expira, permita uma pequena tentativa de recuperação em vez de enviar toda a fila de espera de uma vez. Uma tentativa bem-sucedida pode restaurar a elegibilidade; outra falha pode prolongar a pausa segundo uma política limitada.
Escolha a sonda para o trabalho que deve prever. Uma ligação TCP bem-sucedida não é uma transação HTTP ou SOCKS completa. Uma página de verificação de IP não relacionada não estabelece que o destino necessário é alcançável ou permitido.
Nenhuma duração universal de arrefecimento decorre da palavra proxy. Defina-a a partir do orçamento de latência da operação, do comportamento do serviço e das consequências de outra tentativa falhada. Preserve o registo do endpoint para que uma interrupção temporária não se torne silenciosamente numa perda permanente de capacidade.