인프런 커뮤니티 질문&답변
작성한 질문수
[TCC 구현하기(2) - 동시성문제 해결하기] 질문
작성
·
5
0
주문에 대한 멱등성과 동시성 처리 완료
List<ProductReservation> exists = productReservationRepository.findByRequestId(command.requestId());
// 같은 requestId에 대해서 멱등성을 보장(주문 단위)
if (!exists.isEmpty()) {
long totalPrice = exists.stream().mapToLong(ProductReservation::getReservedPrice).sum();
log.info("이미 처리된 예약 건 입니다. requestId: {}", command.requestId());
return new ProductReserveResult(totalPrice);
}
이 후, 상품에 대한 동시성을 위해서 낙관락을 사용하셨는데요,
주문이 많이 들어오는 서비스에 대해서는,
낙관락보다는 비관락이 더 유리한게 맞을까요?
질문도 질문이지만, 강사님 강의 정말 잘듣고 있습니다! 감사합니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 홍승현님!
질문해주신 내용과 관련하여 설명드리겠습니다.
낙관적 락(Optimistic Lock) vs 비관적 락(Pessimistic Lock)
낙관적 락(Optimistic Lock): 데이터 변경 충돌이 드물다고 가정하고, 데이터 변경 시에만 버전 번호를 체크하여 충돌 여부를 판단합니다. 충돌이 발생하면 재시도하거나 롤백합니다. 일반적으로 충돌이 적은 경우, 낙관적 락이 성능 면에서 유리합니다.
비관적 락(Pessimistic Lock): 데이터에 대한 변경이 빈번하고 충돌이 예상되는 경우, 데이터에 접근하는 동안 락을 걸어 다른 트랜잭션이 해당 데이터를 변경하지 못하도록 합니다. 데이터 갱신 시점에 데이터 접근이 순서대로 이루어져야 하는 경우 비관적 락이 유용합니다.
주문이 많이 들어오는 서비스에서는 상황에 따라 두 접근 방식 중 적절한 것을 선택하셔야 합니다.
낙관적 락이 적합한 경우: 대부분의 경우에서 충돌이 드물거나, 성능을 극대화하고자 할 때.
비관적 락이 적합한 경우: 데이터 변경 충돌이 빈번하거나, 해당 데이터의 일관성이 매우 중요할 때.
추가적인 고려사항
시스템 특성: 서비스 특성 및 트래픽 패턴에 따라 선택이 달라질 수 있습니다. 예를 들어, 널리 분산된 시스템에서는 낙관적 락이 더 나을 수 있습니다.
응답 속도: 비관적 락은 락을 거는 동안 응답 속도가 느려질 수 있으므로, 사용자 경험 측면에서도 고려해야 합니다.
실제 구현 시 고려할 점
- 재시도 로직을 통해 낙관적 락의 실패를 보완하거나,
- 데이터베이스 락 타임아웃을 활용하여 비관적 락의 블로킹 이슈를 해결하는 방안을 고려해 볼 수 있습니다.
구체적인 구현 방안은 서비스의 구조와 요구사항에 따라 달라질 수 있으므로, 트랜잭션 특성과 비즈니스 요구사항을 충분히 고려하여 설계하시길 추천드립니다.
관련 내용으로는 TCC 패턴과 트랜잭션 격리수준 조정 등에 대한 참고를 추천드립니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.