20240229 (목) 최종 프로젝트 티켓레이더 1주차 - CRUD 마무리단계

오늘 한 일

1. Event(price,seat) 리팩토링

이렇게 되어 있던 것을

Create와 Update Request를 합치고 아래에 해당 코드를 짜주었다

 

그리고 1번사진을 이렇게 바꾸었다.

 

2. Seat 테이블 이름 변경

 

Seat 테이블의 이름을 AvailableSeat로 변경하였다.

이유는 Seat 테이블이 그냥 좌석이 주체가 되는게 아닌

유저가 티켓을 구매할때 이 Seat 테이블을 기준으로 예약이 가능한지, 아닌지를 구분하는 용도로 쓰이기 때문에

그냥 “좌석”이라는 단어인 Seat는 직관적이지 않다.

 

3. 락 키 구현 관련 정책설정

 

우리는 동시성 제어를 해볼것인데 락을 구현할때 이 락이 걸리는 시점과 락키를 구분지을 방법을 의논하였다.

우선 유저입장에서 티켓을 예매하고 결제하는 과정을 써보자면

1. 예매할 공연(뮤지컬, 연극 등등)을 고른다.
2. 공연 선택 후 날짜 > 좌석등급 > 좌석번호 선택
3. 결제 진행 누르기
4. 결제 정보 입력
5. 결제 완료 버튼 누름 <<여기까지가 유저가 하는 부분이다.
6. 넘어온 결제 정보로 송금 진행 <<여기부터는 시스템상에서 자동적으로 진행 된다.
7. 최종적으로 송금까지 받아오면 데이터상으로도 결제 완료

그렇다면 우리는 여기서 의논해볼 점이 2가지이다.

• 락키를 생성할 기준은 무엇인가!
• 락 점유를 시작할 부분은 어디인가!

이제 하나하나 정해보도록 하자

락키가 생성되는 기준은 어떤 부분을 기준으로 락점유를 못하게 할것인가 라는 것과 같다.

우리는 락 키를 공연, 좌석등급, 좌석 번호를 기준으로 생성하기로 결정하였다.

그리고 락 점유를 시작할 부분은 어디인가!

처음엔 3번에 점유를 시작하고 5번에 해제를 하는걸 생각하였다.

하지만 이렇게 되면 문제점은 락 점유시간을 길게 잡아야하고 그동안 다른 대기열이 길어지는 문제점이 있었다.

또 락점유를 길게잡으면서 이미 결제까지 완료 했지만 데드락이 발생하여 락을 점유하고있는 상황이 길어질수가 있다.

그리하여 생각해낸게 은행에서도 실제 인출, 송금 과정이 일어나니까 이 시점을 락으로 잡으면 어떻겠냐는 얘기가 나왔다.

이렇게하면 락점유를 10~20초정도로만 잡아도 되고 조금더 선착순에 가까운 적용법이 아닌가 싶었다.

 

---

휴일엔 느긋하게 쉬어줘야겠다!