-
Notifications
You must be signed in to change notification settings - Fork 1
트러블 슈팅 ‐ 동시성 문제 해결
Mingi Kim edited this page May 7, 2024
·
1 revision
- 여러 사람들이 한 좌석으로 예매할때 발생하는 문제를 방지하기 위하여 여러 조치를 취했다. (예약이 된 좌석이라면 예매 불가, 예약과 좌석의 일대일 관계 설정 등)
- 여러 스레드가 동일한 좌석을 예약하려 할 때 **
DataIntegrityViolationException
**이 발생했다. - 에러 로그를 추적한 결과, 예약 정보를 저장할때 같은 DB에 일대일 관계로 매핑된 요소가 여러번 저장되려고 시도되었고, 거기에서 위와 같은 에러가 발생하게 되었음을 알 수 있었다.
❎ @Syncronized 어노테이션 사용
✔️ 비관적 락 사용 << 최종 채택!
❎ 낙관적 락 사용
✔️ 스핀 락 사용
❎ 분산 락 사용
- @Syncronized : 간단하지만 대용량 트래픽이 들어올 경우 성능이 급격하게 저하되어 적합하지 않다고 판단했다.
- 낙관적 락의 경우 db가 변경될 때 락을 거는 방식이다. 동시성 문제가 발생하는 지점은 db를 읽는 부분이므로 적합하지 않다고 판단했다.
- 분산 락의 경우 서버를 여러개로 나눈 상태였다면 가장 좋은 방법이라 생각하지만 적용 시점에서 단일 서버로 운영하고 있었고, 러닝 커브가 다른 락에 비하여 높다고 판단하여서 보류하였다.
- 우리 프로젝트에서 가장 알맞은 방식은 비관적 락, 스핀 락이라고 판단하였고, 두가지 경우에 대하여 테스트를 진행하였다.
위에서부터 순서대로 Latency, Throughput에 대한 그래프다.
파란 선은 스핀락, 붉은 선은 비관적 락이다.
비관적 락이 전체적인 Latency도 낮고, Throughput도 더 높은 경향성을 보여서 프로젝트에 더 적합해보이는 비관적 락을 채택하였다.
비관적 락은 채택함으로써,