현재 테스트 중입니다: 완료되면 GitHub 코드를 오픈할 예정입니다.

RPC 종류

프레임tag가 RPC 종류를 결정합니다. payload는 모두 openraft 타입을 postcard로 직렬화한 것입니다.

tag이름요청 payload응답 payload역할
1VoteVoteRequestVoteResponse리더 선거 — 후보가 다른 노드에 투표를 요청
2AppendEntriesAppendEntriesRequestAppendEntriesResponse로그 복제 + 하트비트 — 리더가 복제 명령을 팔로워에게 전파
3FullSnapshot(Vote, SnapshotMeta, snapshot_bytes) 튜플SnapshotResponse뒤처진 노드에 스냅숏 전체를 전송
4TransferLeaderTransferLeaderRequestTransferLeaderResponse계획된 리더 교체 전에 catch-up한 다른 voter로 leadership 이양
16JoinJoinRequestJoinResponseleader가 발급한 one-shot 자격으로 새 NodeId learner admission 시작
  • Vote — 리더가 죽으면 하트비트가 끊긴 노드가 후보가 되어 투표를 요청하고, 과반 득표한 노드가 새 리더가 됩니다.
  • AppendEntries — 리더가 커밋할 락 명령을 로그 엔트리로 실어 보냅니다. 엔트리가 없는 AppendEntries가 곧 하트비트입니다 — 별도의 하트비트 메시지가 없습니다.
  • FullSnapshot — 로그로 따라잡기에 너무 뒤처진(또는 새로 합류한) 노드에게 현재 상태 전체를 보냅니다. 스트리밍 없이 프레임 하나로 통째로 전송됩니다.
  • TransferLeader — 제거할 노드가 현재 리더인 경우 새 voter 세트의 다른 catch-up 노드로 leadership을 먼저 이양합니다. source는 현재 리더, target은 다른 현재 voter여야 합니다.
  • Join — 현재 active replacement의 NodeId·incarnation·주소·만료 시각에 묶인 one-shot 자격을 leader가 검증합니다. admission 중인 peer는 Join 외의 RPC를 보낼 수 없고, 자격은 재사용할 수 없습니다.

흐름 — 리더가 죽었을 때

노드 A
노드 B
노드 C
리더의 하트비트 단절 감지 → 후보로 전환
Vote · 투표 요청
Vote · 투표 요청
찬성
자신 포함 과반 득표 → 새 리더
AppendEntries (엔트리 없음 = 하트비트)
AppendEntries (엔트리 없음 = 하트비트)
합의 RPC (Raft)

선출된 새 리더의 첫 하트비트가 도착하는 순간부터 클러스터는 정상 서비스로 돌아옵니다. 기본 500ms heartbeat/2000ms 미응답 설정에서는 장애 감지와 선거를 합쳐 약 2.3~2.5초가 기준입니다. 정상 운영 중의 AppendEntries(로그 복제) 흐름은 복제 명령을 참고하세요.

용어

  • 로그 복제(log replication) — 리더가 결정한 명령을 순서 붙은 일지(log)로 만들어 팔로워들이 그대로 받아 적게 하는 것. 같은 일지를 같은 순서로 적용하면 모든 노드가 같은 상태가 됩니다.
  • 하트비트(heartbeat) — "나 살아 있음"을 알리는 주기 신호. 이게 끊기면 팔로워들이 리더가 죽었다고 판단하고 선거를 시작합니다.