좌석 분산 락과 Hold 동시성 경합 문제

대규모 티켓팅 서비스에서 좌석 선점(Hold)은 두 가지 방식으로 동시에 일어납니다. 추천 자동 배정과 일반 좌석 선택이 같은 블럭에서 충돌할 수 있으며, 동시성 제어 없이는 중복 배정 문제가 발생합니다.

두 가지 Hold 방식

SETNX → Redisson 전환

초기에 Spring Data Redis의 setIfAbsent 기반 단순 분산 락을 썼으나,Watch Dog 부재, 소유자 검증 불가, 재시도 로직 직접 구현 등의 문제로 Redisson RLock으로 전환했습니다.

시나리오 1: 추천 vs 추천 (같은 블럭)

블럭 단위 Redisson RLock + Watch Dog. 추천 배정은 조회 → 연석 계산 → DB UPDATE → Hold 생성의 복합 연산이므로, 블럭 단위로 락을 잡습니다.

락-트랜잭션 분리 구조 (핵심 설계)

SeatAssignmentService (락 관리, @Transactional 없음)
  └─ 🔒 락 획득
       └─ SeatAssignmentTransactionalService (@Transactional)
            └─ 조회 → 연석 계산 → markBlockedIfAvailable() → Hold 생성
            └─ 트랜잭션 커밋 ✅
       └─ 🔓 락 해제

이 구조는 트랜잭션 커밋이 반드시 락 해제보다 먼저 완료됨을 보장합니다.@Transactional이 걸린 서비스에서 직접 락을 관리하면, Spring AOP 프록시 특성상 락 해제 → 트랜잭션 커밋 순서가 될 수 있어 위험합니다.

동작 흐름

추천 유저A: 204블럭 5연석 요청
추천 유저B: 204블럭 3연석 요청 (동시)

유저A: 🔒 seat:recommendation:match:10:block:204 획득
유저B: 🔒 같은 키 획득 시도 → 대기 (최대 3초)

유저A: 빈 좌석 조회 → [3열 1~5번] 배정 → Hold 생성 → 트랜잭션 커밋
유저A: 🔓 락 해제

유저B: 🔒 락 획득 성공
유저B: 빈 좌석 조회 → [3열 1~5번]은 BLOCKED → [3열 6~8번] 배정

시나리오 2: 일반 vs 일반 (같은 좌석)

좌석 단위 Redisson RLock. 유저가 직접 선택한 좌석들만 잠그며, seatId 정렬 순 획득 + 역순 해제로 데드락을 방지합니다.

데드락 방지: seatId 정렬 순 획득

유저A가 좌석 [3, 1, 2]를 선택 → 정렬: [1, 2, 3] → 순서대로 락 획득
유저B가 좌석 [2, 3, 1]을 선택 → 정렬: [1, 2, 3] → 순서대로 락 획득

항상 같은 순서로 락을 획득하므로 데드락이 발생하지 않음.

시나리오 3: 추천 ON vs 추천 OFF 교차 충돌

추천 블럭 락과 일반 좌석 락은 서로 다른 키를 사용합니다. 따라서 추천 유저가 블럭 락을 잡고 있어도, 일반 유저는 같은 블럭의 좌석을 잡을 수 있습니다. 이 경우 조건부 UPDATE (Optimistic Lock)로 충돌을 감지합니다.

UPDATE match_seats
SET sale_status = 'BLOCKED'
WHERE id = :matchSeatId
  AND sale_status = 'AVAILABLE'
-- return 0이면 이미 다른 유저가 선점 → 롤백 후 재시도

충돌 시 최대 3회 재시도하며 다른 연석 구간을 탐색합니다.

충돌 시나리오별 처리 정리

SeatHold 엔티티와 TTL 관리

SeatHold는 seat_holds 테이블에 저장되며, match_seat_id에 UK 제약이 있어 좌석당 하나의 Hold만 허용합니다. TTL은 5분이며, SeatHoldCleanupScheduler가 60초 간격으로 만료 Hold를 정리합니다.

Hold 연장

유저가 이미 Hold 중인 좌석을 다시 요청하면 기존 Hold의 expiresAt을 갱신합니다 (새 Hold 생성 없이 연장).

트러블슈팅 히스토리