[3주차] 예매 api 구현 및 동시성 제어를 위한 분산락

[eedys1234]

제목(title)

주차와 함께 변경 사항을 요약하여 구성해 주세요.
ex: [1주차] 사용자 로그인 기능 구현

• 예매 API 구현

작업 내용

이번 PR에서 진행된 주요 변경 사항을 기술해 주세요.
코드 구조, 핵심 로직 등에 대해 설명해 주시면 좋습니다. (이미지 첨부 가능)
ex: ConcurrentOrderService에 동시 주문 요청 처리 기능 추가

• 비관적 Lock, 낙관적 Lock, AOP 방식의 분산 락을 구현하였습니다.
• 메시지 발송 관련하여 EventListener와 Async를 통해 도메인 간의 결합도를 낮추었으며, 예약 정보 트랜잭션이 Commit 될 경우 발송 로직이 수행되도록 구현하였습니다.

발생했던 문제와 해결 과정을 남겨 주세요.

ex) 문제 1 - 다수의 사용자가 동시에 같은 리소스를 업데이트할 때 재고 수량이 음수로 내려가는 데이터 불일치 문제 발생
해결 방법 1 - Redis SET 명령어에 NX(Not Exists)와 PX(Expire Time) 옵션을 활용해 락을 설정했습니다. 이유는 ~

• Lock Key의 범위에 대해 고민하였습니다. Lock Key에 대한 범위를 너무 크게 잡을 경우 성능 저하가 우려되어, Lock Key의 범위를 좁히되 명확하게 정의할 수 있는 키를 고민하였습니다. 그 중 ScreeningId(상영 시간 ID)와 예약 하고자하는 좌석 정보 중 Row(좌석 중 A, B, C를 의미)를 통해 Key를 구성하였습니다. 비즈니스 로직 상 연속된 좌석(A1, A2, A3 등등)만을 예매할 수 있기 때문에 Row값에 대해서만 검증하면 된다고 판단하였습니다.

이번 주차에서 고민되었던 지점이나, 어려웠던 점을 알려 주세요.

과제를 해결하며 특히 어려웠던 점이나 고민되었던 지점이 있다면 남겨주세요.

• 메시지 발송을 위해 별도의 도메인을 만들었으며, Facade를 통해 각각의 서비스를 호출하는 방식으로 구성하였습니다. 이 구조가 적절한지 고민이 많았습니다.
• 동시성에 대한 테스트코드를 작성하는데, 테스트에 대한 검증이 적절한지, 또한 성능 테스트를 어떻게 진행해야하는지 고민이 많았습니다.

리뷰 포인트

리뷰어가 특히 의견을 주었으면 하는 부분이 있다면 작성해 주세요.

ex) Redis 락 설정 부분의 타임아웃 값이 적절한지 의견을 여쭙고 싶습니다.

• 락 설정 부분 중 타임아웃 시간과 대기시간이 궁금합니다.

기타 질문

추가로 질문하고 싶은 내용이 있다면 남겨주세요.

ex) 테스트 환경에서 동시성 테스트를 수행하였고, 모든 케이스를 통과했습니다. 추가할 테스트 시나리오가 있을까요?