Tipos de RPC
O tag em um quadro decide o tipo de RPC. Todo payload é um tipo do openraft serializado com postcard.
| tag | Nome | Payload da requisição | Payload da resposta | Papel |
|---|---|---|---|---|
1 | Vote | VoteRequest | VoteResponse | Eleição de líder — um candidato pede o voto de outros nós |
2 | AppendEntries | AppendEntriesRequest | AppendEntriesResponse | Replicação de log + heartbeat — o líder propaga comandos replicados aos seguidores |
3 | FullSnapshot | uma tupla (Vote, SnapshotMeta, snapshot_bytes) | SnapshotResponse | Envia o snapshot inteiro a um nó que ficou para trás |
- Vote — quando o líder morre, um nó cujo heartbeat parou se torna candidato e solicita votos; o nó que ganha a maioria se torna o novo líder.
- AppendEntries — o líder carrega comandos de lock para confirmar (commit) como entradas de log. Um AppendEntries sem entradas é o heartbeat — não há uma mensagem de heartbeat separada.
- FullSnapshot — envia todo o estado atual a um nó atrasado demais para alcançar via o log (ou um que acabou de entrar). Enviado inteiro, em um único quadro, sem streaming.
Fluxo — Quando o Líder Morre
Nó A
Nó B
Nó C
detecta que o heartbeat do líder sumiu → torna-se candidato
Vote · solicitando voto
Vote · solicitando voto
sim
maioria incluindo ele mesmo → novo líder
AppendEntries (sem entradas = heartbeat)
AppendEntries (sem entradas = heartbeat)
RPC de consenso (Raft)
No momento em que chega o primeiro heartbeat do líder recém-eleito, o cluster volta ao serviço normal — o intervalo total costuma ser de 0,5 a 1 segundo. Veja Comandos Replicados para o fluxo do AppendEntries (replicação de log) durante a operação normal.
Terminologia
- Replicação de log — o líder transforma seus comandos decididos em um log ordenado e faz os seguidores registrá-lo palavra por palavra. Aplicar o mesmo log na mesma ordem leva todo nó ao mesmo estado.
- Heartbeat — um sinal periódico de "estou vivo". Quando ele para, os seguidores concluem que o líder morreu e iniciam uma eleição.