Ticketing Protocolo (Cluster) — Servidor ↔ Servidor
O protocolo RPC entre pares, usado somente no modo cluster. Os nós compartilham um único estado de lock via consenso Raft — toda mudança de estado do lock (aquisição, liberação, expiração) só é aplicada após a proposta do líder → replicação da maioria → commit, então a exclusão mútua se mantém mesmo durante uma partição ou failover. Veja Como Funciona para a explicação conceitual.
Fluxo — de uma aquisição até seu commit
O líder transforma o comando de lock em um comando replicado, o carrega em um RPC AppendEntries, e confirma (commit) assim que uma maioria incluindo ele mesmo o registrou (com 3 nós, o líder mais o seguidor 1 já bastam — ele não espera pelo restante). A resposta ao cliente só sai após o commit, então, uma vez que você recebeu uma resposta, esse lock está escrito na maioria.
Regras de Porta e Endereço
- O RPC entre pares usa uma porta Raft dedicada = porta do cliente + 1000 (por exemplo,
5225→6225). É derivada automaticamente, sem uma chave de configuração separada, e só escuta no modo cluster. Seu firewall precisa abrir as duas portas. - A configuração (
cluster_self/cluster_peers) sempre contém o endereço do cliente. Apenas ao discar (dial) para um par é que +1000 é somado à porta — o endereço de redirecionamentoM(movido) entregue aos clientes é sempre o endereço de cliente simples. - Os papéis são distinguidos puramente pela porta — não há etapa dentro do protocolo para diferenciar cliente e par. Veja Conexão e Autenticação para a ordem de conexão e as regras de autenticação/TLS.
Sumário
- Servidor a Servidor
- Parâmetros do Raft
- Configuração (Variáveis de Ambiente)
- Procedimento de Reinício sem Interrupção (Rolling)
Veja Também
- Uma explicação simples de eleição de líder, commits por maioria e cenários de falha — Como Funciona
- Como um cliente encontra o líder —
M· Movido, Regras de Correspondência de Resposta - Configurações reais de implantação (Docker, Kubernetes etc.) — Implantação do Servidor Ticketing