3PC(Three-Phase Commit, 세 단계 커밋)는 2PC의 블로킹 문제를 해결하기 위해 준비(Prepare), 사전 커밋(Pre-Commit), 커밋(Commit) 3단계로 분산 트랜잭션을 처리하는 프로토콜이다.
2PC의 문제점 복습
2PC 블로킹 시나리오:
1. 코디네이터가 COMMIT 전송 후 장애
2. 참여자 일부는 COMMIT 수신, 일부는 미수신
3. 코디네이터 복구 전까지 트랜잭션 잠금 (블로킹)
4. 코디네이터가 SPOF
3PC 목표: 타임아웃으로 블로킹 없이 진행 가능
3PC 프로토콜
단계 1: CanCommit?
코디네이터 → 참여자: "커밋 가능?"
참여자 → 코디네이터: YES / NO
단계 2: PreCommit
모두 YES → 코디네이터 → 참여자: "사전 커밋 준비"
참여자: Undo 로그 정리, 커밋 직전 상태 저장
→ ACK 응답
단계 3: DoCommit
모든 ACK → 코디네이터 → 참여자: "실제 커밋"
타임아웃 처리:
단계 2에서 DoCommit 미수신 → 참여자 타임아웃 → 커밋
(CanCommit만 받은 상태에서 타임아웃 → 어보트)
2PC vs 3PC 비교
| 항목 | 2PC | 3PC |
|---|
| 단계 | 2 | 3 |
| 블로킹 | O (코디네이터 장애 시) | X (타임아웃으로 진행) |
| 네트워크 파티션 | 불안전 | 불안전 (뇌분열 가능) |
| 메시지 수 | 2N | 3N |
| 실용성 | 실제 DB 사용 | 이론적 (잘 사용 안 함) |
한계와 현실
3PC도 네트워크 파티션 시 "뇌분열(Split-Brain)" 문제 발생:
파티션으로 일부는 PreCommit, 일부는 CanCommit 상태
각자 타임아웃 → 불일치 커밋/어보트
결론:
CAP 정리상 완벽한 분산 커밋 프로토콜 불가
실용적 대안: SAGA + 보상, 이벤트 소싱, 최종 일관성
강한 일관성 필요 시: 분산 DB (Spanner, CockroachDB)의
TrueTime / Raft/Paxos 기반 합의
관련 문서
- •[[two-phase-commit|2PC (두 단계 커밋)]]
- •[[sagas-compensation|SAGA 보상 트랜잭션]]
- •[[consensus-algorithms|합의 알고리즘]]
