Delivery 프로젝트의 배달 주문의 프로세스를 간략히 표현하면 위의 그림과 같습니다.
1. User는 장바구니에 담아 놓은 메뉴로 주문을 요청합니다.
2. Owner는 주문 요청을 승인합니다.
3. Rider는 승인된 주문을 배달 접수를 합니다.
4~5. 다른 Rider가 동일한 주문에 배달을 접수하면 예외를 발생합니다.
언뜻 보기에 문제가 없어 보이지만 그렇지 않았습니다.
여러 명의 Rider가 동시에 동일한 주문에 배달 접수할 때, 모든 Rider가 접수가 되는 문제가 생길 수 있습니다. DB엔 어떤 Rider가 저장될지는 아무도 모릅니다.
마치 멀티스레드 환경에 공유자원을 사용해 문제가 발생하는 이슈와 같습니다.
빨간색 부분은 주문의 상태를 보고 이미 다른 Rider가 배달 접수를 했다면 예외를 던지는 부분입니다.
Rider마다 요청은 스레드로 처리되기 때문에 충분히 동시에 저 조건문을 통과할 수 있는 것입니다.
해결 방법은 트랜잭션의 격리 수준을 높이는 것입니다.
@Transactional(isolation = Isolation.SERIALIZABLE)
격리 수준을 높여 DB의 데이터 처리를 순차적으로 진행하게 만드는 것입니다.
순차적으로 진행되기 때문에 성능에 문제가 없는지 확인을 해야 합니다.
(어떻게 성능 테스트를 할지 고민해봐야겠습니다.)
'project > Delivery' 카테고리의 다른 글
[Delivery] Redis에 session 저장하기 (0) | 2021.12.31 |
---|---|
[Delivery] 반복되는 로직을 AOP로 분리하기 (0) | 2021.12.31 |
[Delivery] 프로젝트 구조 (0) | 2021.12.28 |
댓글