Algoritmos de
Load Balancer

SEÇÃO 01

O que o algoritmo decide

O algoritmo de load balancer é a regra usada para decidir para qual servidor cada nova requisição será enviada.

Exemplo:

Usuário → Load Balancer → Servidor A
                       → Servidor B
                       → Servidor C

O load balancer precisa escolher um deles. Essa escolha pode ser estática ou dinâmica.

SEÇÃO 02

Algoritmos estáticos

Eles não analisam profundamente o estado atual dos servidores. Apenas seguem uma regra predefinida.

Round Robin

Distribui as requisições em sequência:

Requisição 1 → Servidor A
Requisição 2 → Servidor B
Requisição 3 → Servidor C
Requisição 4 → Servidor A

É como distribuir cartas entre jogadores.

Vantagem: simples e barato.

Problema: pressupõe que todos os servidores têm capacidade parecida e que todas as requisições dão aproximadamente o mesmo trabalho.

Por exemplo, o Servidor A pode receber uma requisição pesada e continuar ocupado, mas receber outra quando chegar novamente sua vez.

Weighted Round Robin

É o Round Robin com pesos diferentes.

Exemplo:

Servidor A: peso 3
Servidor B: peso 2
Servidor C: peso 1

A distribuição pode ficar aproximadamente:

A → A → A → B → B → C

O servidor mais potente recebe mais tráfego.

É útil quando as máquinas têm capacidades diferentes.

IP Hash

O load balancer usa o IP do cliente para calcular um hash e escolher o servidor.

IP do usuário → função hash → Servidor B

O mesmo IP normalmente continua sendo enviado para o mesmo servidor.

Isso ajuda quando a aplicação guarda sessão localmente:

Usuário Marcelo → sempre Servidor B

O problema é que pode haver distribuição desigual. Muitos usuários podem acabar concentrados no mesmo servidor. Além disso, vários usuários podem compartilhar um único IP, como em redes corporativas.

SEÇÃO 03

Algoritmos dinâmicos

Eles observam o estado atual dos servidores antes de decidir.

Least Connections

Envia a nova requisição para o servidor com menos conexões abertas.

Servidor A: 100 conexões
Servidor B: 45 conexões
Servidor C: 70 conexões

Nova requisição → Servidor B

É melhor que Round Robin quando as conexões duram tempos diferentes.

Por exemplo, uma conexão WebSocket pode ficar aberta por vários minutos, enquanto uma requisição HTTP comum termina rapidamente.

O problema é que quantidade de conexões não representa necessariamente esforço. Uma conexão pode consumir muito mais CPU do que outra.

Weighted Least Connections

Também escolhe com base nas conexões abertas, mas considera a capacidade de cada servidor.

Servidor A: máquina potente, peso 4
Servidor B: máquina média, peso 2
Servidor C: máquina fraca, peso 1

Mesmo que o Servidor A tenha mais conexões, ele ainda pode receber tráfego por conseguir suportar mais carga.

É uma versão mais realista do Least Connections para infraestrutura desigual.

Weighted Response Time

Considera principalmente:

• tempo de resposta do servidor;
• quantidade de conexões abertas;
• peso ou capacidade configurada.

Exemplo:

Servidor A: 80 ms
Servidor B: 300 ms
Servidor C: 120 ms

A nova requisição provavelmente será enviada ao Servidor A.

Esse algoritmo tenta direcionar usuários para os servidores que estão respondendo mais rápido.

O cuidado é que uma medição temporária pode enganar. Um servidor pode estar lento por poucos segundos, e não necessariamente com problema permanente.

Resource-Based

Analisa recursos reais de cada servidor, como:

CPU
memória RAM
fila interna
uso de disco

Exemplo:

Servidor A: CPU 90%, RAM 80%
Servidor B: CPU 35%, RAM 40%
Servidor C: CPU 60%, RAM 50%

Nova requisição → Servidor B

É uma decisão mais inteligente, mas também exige mais infraestrutura. Normalmente existe um agente ou mecanismo de monitoramento informando ao load balancer o estado de cada máquina.

SEÇÃO 04

Health checks

Health check não é exatamente um algoritmo de distribuição, mas trabalha junto com ele.

O load balancer testa periodicamente algo como:

GET /health

Servidor saudável:

{
  "status": "ok"
}

Servidor problemático:

timeout
erro 500
conexão recusada

Se um servidor estiver com problema, ele é removido temporariamente da distribuição:

Servidor A: saudável
Servidor B: fora do ar
Servidor C: saudável

Tráfego → somente A e C

SEÇÃO 05

Qual escolher?

Para servidores iguais e uma aplicação simples:

Round Robin

Para servidores com capacidades diferentes:

Weighted Round Robin

Para conexões longas, como WebSocket:

Least Connections

Para servidores diferentes e conexões longas:

Weighted Least Connections

Para otimizar velocidade percebida:

Weighted Response Time

Para infraestrutura grande e altamente monitorada:

Resource-Based

Para manter o mesmo usuário no mesmo servidor:

IP Hash

Na prática, uma escolha comum e equilibrada é:

Least Connections + health checks

E, quando os servidores têm capacidades diferentes:

Weighted Least Connections + health checks

SEÇÃO 06

Ideia central

A ideia central é:

Round Robin → distribui por ordem
Least Connections → procura quem está menos ocupado
Response Time → procura quem está respondendo mais rápido
Resource-Based → procura quem tem mais recursos disponíveis
IP Hash → mantém o cliente associado a um servidor