Q. 예약 부분에서 왜 Redis랑 DB 유니크 제약조건을 둘 다 쓰는지 모르겠다 DB 유니크 제약조건만 써도 되는데 왜 굳이 Redis를 사용했는가?
Redis 분산 락 vs DB 유니크 제약조건
현재 코드에서 둘 다 사용하는 이유:
1. 성능상의 이유
// createReservation 메서드에서
String lockKey = String.format("reservation:lock:%d:%s:%s", trainerId, reservationDate, reservationTime);
RLock lock = redissonClient.getLock(lockKey);Redis 락: 메모리 기반으로 빠른 락 획득/해제
DB 제약조건: 디스크 I/O가 필요해서 상대적으로 느림
2. 동시성 처리 방식의 차이
Redis 분산 락의 장점:
여러 서버(인스턴스)에서 동시에 같은 시간대 예약을 시도할 때 사전에 차단
락을 획득하지 못한 요청은 즉시 실패 처리 가능
불필요한 DB 트랜잭션을 방지
DB 유니크 제약조건만 사용할 경우:
모든 요청이 DB까지 진행 → 트랜잭션 시작 → 제약조건 위반 시 롤백
DB 부하 증가 및 불필요한 리소스 사용
3. 실제 시나리오
동시에 1000명이 같은 트레이너의 같은 시간을 예약 시도:
Redis 락만 사용:
- 1명만 락 획득, 999명은 즉시 실패 반환
- DB 접근 최소화
DB 제약조건만 사용:
- 1000개 트랜잭션 모두 시작
- 999개는 제약조건 위반으로 롤백
- DB 부하 심함
4. 방어적 프로그래밍
현재 코드는 이중 체크를 하고 있습니다:
// Redis 락 내에서도 한번 더 체크
boolean alreadyExists = reservationRepository.existsByTrainerAndReservationDateAndReservationTime(
trainer, reservationDate, reservationTime
);DB 유니크 제약조건만으로도 데이터 정합성은 보장됩니다.
Redis 락은 성능 최적화를 위한 선택사항이다.
개선 방안:
트래픽이 적다면 → DB 유니크 제약조건만 사용
고트래픽이라면 → 현재처럼 Redis 락 + DB 제약조건
중간 단계 → Redis 락만 사용하고 DB 제약조건 제거
