2PC의 병목

준비는 각 DB가 하지만, 결론은 하나의 결정 지점에서만 납니다

2PC에서는 참여자마다 로컬 트랜잭션을 끝낼 수 있어도 스스로 commit 할 수 없습니다. 모두가 prepared 상태로 멈춘 뒤, 코디네이터의 마지막 결정 한 번을 기다립니다.

하나의 전역 작업
주문 완료 요청 하나가 여러 서비스 DB를 함께 바꿉니다 주문 DB, 결제 DB, 재고 DB가 모두 같은 성공/실패 결과를 가져야 하므로 분산 트랜잭션이 필요합니다.
1. 각 참여자 자기 DB 변경은 끝내지만 아직 확정은 아님

주문 서비스 DB

  • 로컬 변경 완료 주문 상태를 갱신할 준비를 마칩니다.
  • prepared + 락 유지 최종 통보 전까지 commit 하지 않고 대기합니다.

결제 서비스 DB

  • 로컬 변경 완료 결제 승인 결과를 반영할 준비를 마칩니다.
  • prepared + 락 유지 자체 판단 없이 중앙 결정을 기다립니다.

재고 서비스 DB

  • 로컬 변경 완료 재고 차감 결과를 반영할 준비를 마칩니다.
  • prepared + 락 유지 관련 락을 쥔 채 상태를 고정합니다.
2. 중앙 결정 모든 참여자가 같은 결론을 받아야 함
Coordinator
최종 commit / rollback는 한 곳에서만 결정됩니다

prepare 이후에는 참여자들이 먼저 나아갈 수 없어서, 전역 트랜잭션의 마지막 한 걸음이 코디네이터에 집중됩니다.

commit 신호 모든 DB가 같은 시점에 확정됩니다.
rollback 신호 모든 DB가 같은 시점에 되돌아갑니다.
3. 지연 또는 장애 게이트가 열리지 않으면 전체가 함께 멈춤
코디네이터가 늦거나 장애가 나면 prepared 상태가 길어지고, 참여자들은 락을 유지한 채 기다립니다

그래서 2PC의 핵심 문제는 개별 서비스 속도보다, 모든 참여자가 같은 최종 결정에 묶여 블로킹된다는 점입니다.

prepared 상태 유지 락 유지 후속 트랜잭션 지연 단일 장애점 노출
핵심: 2PC는 각 DB가 독립적으로 일하는 구조처럼 보여도, 실제로는 전역 트랜잭션의 마지막 결정이 하나의 코디네이터에 집중되기 때문에 병목과 블로킹이 생깁니다.