아직 티켓팅 서비스를 할지 정해지지는 않았지만, 현재 티켓팅 로직은 실제 서비스를 하는 데 무리가 있습니다.
우선 첫 번째로 공연에만 티켓팅을 할 수 있으니, 시범적으로 간식 행사 티켓팅 또는 응원전 티켓팅을 하려면 공연이 없는데 불구하고, 축제를 생성 후 공연을 만들고 티켓을 추가해야 합니다.
이 때문에 어플의 축제 목록에 사용자들이 티켓팅을 위한 축제를 조회할 수 있는 문제가 생깁니다.
두 번째로 한 사람 당 하나만 예매가 가능하게 하드 코딩 되어있어 개발 환경에서 티켓팅 테스트 또는 부하 테스트 시 코드를 수정해야 하는 문제가 있습니다.
세 번째로 동시성 문제를 막기 위해 MySQL의 쓰기 락을 사용하고 있어서 티켓팅 요청이 락으로 인해 여러 요청이 오더라도 한 건씩 처리되고, 대기하는 요청 때문에 스레드 풀이 잠깐 고갈되어 다른 요청에서 티켓팅과 무관한 처리를 할 수 없게 됩니다.
(비관적 락으로 동시성을 제어하는 구조이기 때문에 테스트 시 통합 테스트 수준에서 실행해야 하는 문제도 있습니다)
따라서 이러한 문제를 해결하려면 MySQL로 비관적 락을 사용하는 게 아닌, 별도의 구현체를 사용해서 임계 영역을 구분해야 하고, 임계 영역에 진입할 때 상호 배제를 통해 한 요청만 들어오도록 하는 게 아닌, 티켓의 재고 개수에 해당하는 세마포어로 임계 영역에 진입하도록 하여 동시성 성능을 높여야 합니다.
첫 번째와 두 번째 문제는 코드 레벨에서 처리할 수 있을 것 같은데, 세 번째 문제를 해결하려면 아마 레디스를 사용해야 할 것 같네요. 😂
✨ 세부 내용
아직 티켓팅 서비스를 할지 정해지지는 않았지만, 현재 티켓팅 로직은 실제 서비스를 하는 데 무리가 있습니다.
우선 첫 번째로 공연에만 티켓팅을 할 수 있으니, 시범적으로 간식 행사 티켓팅 또는 응원전 티켓팅을 하려면 공연이 없는데 불구하고, 축제를 생성 후 공연을 만들고 티켓을 추가해야 합니다.
이 때문에 어플의 축제 목록에 사용자들이 티켓팅을 위한 축제를 조회할 수 있는 문제가 생깁니다.
두 번째로 한 사람 당 하나만 예매가 가능하게 하드 코딩 되어있어 개발 환경에서 티켓팅 테스트 또는 부하 테스트 시 코드를 수정해야 하는 문제가 있습니다.
세 번째로 동시성 문제를 막기 위해 MySQL의 쓰기 락을 사용하고 있어서 티켓팅 요청이 락으로 인해 여러 요청이 오더라도 한 건씩 처리되고, 대기하는 요청 때문에 스레드 풀이 잠깐 고갈되어 다른 요청에서 티켓팅과 무관한 처리를 할 수 없게 됩니다. (비관적 락으로 동시성을 제어하는 구조이기 때문에 테스트 시 통합 테스트 수준에서 실행해야 하는 문제도 있습니다)
따라서 이러한 문제를 해결하려면 MySQL로 비관적 락을 사용하는 게 아닌, 별도의 구현체를 사용해서 임계 영역을 구분해야 하고, 임계 영역에 진입할 때 상호 배제를 통해 한 요청만 들어오도록 하는 게 아닌, 티켓의 재고 개수에 해당하는 세마포어로 임계 영역에 진입하도록 하여 동시성 성능을 높여야 합니다.
첫 번째와 두 번째 문제는 코드 레벨에서 처리할 수 있을 것 같은데, 세 번째 문제를 해결하려면 아마 레디스를 사용해야 할 것 같네요. 😂
⏰ 예상 소요 시간
12시간