APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Round-robin distribui pedidos ou ligações segundo o âmbito da implementação. Pesos permitem refletir capacidade relativa: num modelo ideal com pesos três e um, a primeira participação é 3/4, ou 75%. A medição real depende de elegibilidade, afinidade, duração e perfil de trabalho. least_conn em NGINX considera ligações ativas e pesos, sem medir automaticamente CPU ou custo de cada pedido. Quando algumas ligações duram minutos, contagens semelhantes de novas ligações podem produzir ocupação diferente. Compara o sinal usado pelo algoritmo com a limitação que pretendes gerir. Um nome de algoritmo não substitui observação de latência, erros, filas e recursos por backend.
Aplicação guiada
Afinidade tenta manter um cliente no mesmo destino, mas a chave observada pode agrupar utilizadores. Uma NAT partilhada concentra origens no mesmo IP e pode enviesar ip_hash. Um cookie sticky também pode manter testes no backend antigo durante uma release. Identifica o destino real de cada amostra. Afinidade não replica sessões guardadas em memória: se o processo desaparece, é preciso um desenho de estado e recuperação. Hash consistente pode reduzir remapeamento quando os membros mudam, mas não garante zero alterações nem copia dados. Num caso fictício de ligações longas, avalia least_conn com o mesmo perfil antes de prometer melhoria e confirma limites de cada servidor.
Contagens iguais não provam trabalho igual; afinidade não prova que o estado está replicado.
Armadilhas comuns
Peso como capacidade criada; IP como utilizador único; sticky como replicação; hash consistente como zero remapeamento.
Tópicos relacionados: Encaminhamento e fronteiras TLS · Health checks e prontidão · Retries, limites e origem do cliente
Escolhe o sinal adequado e valida a distribuição e o estado separadamente.
Referência: NGINX HTTP load-balancing methods · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior