상품 판매 시스템 요구사항
1. 초당 수천개의 요청을 감당할 수 있는 시스템을 구축해야 합니다.
2. 계정 별로 구매 가능한 상품 수 제한이 있습니다.
3. 재고 관리가 엄격하게 되어야 합니다.
1. 사용자 별 구매 수량 관리
사용자 식별 값으로 분산락을 걸어 동일 사용자의 상품 구매 작업 동시에 처리되지 않도록 한다.
또한, 요청 마다 구매 수량 계산에 의해 트랜잭션 시간의 증가로 부하가 발생할 수 있으니
사용자의 구매 수량을 Redis 로 관리하도록 해 총 구매 수량 계산 연산이 매번 수행하지 않도록 한다.
2. 상품 재고 관리
상품의 판매 유무 조회 후, 사용처리를 진행할 때, 해당 상품을 동시에 사용처리하는 요청이 많을 경우, 동시성 문제가 발생할 수 있다.
상품은 하나이나, 모든 요청이 구매 가능하다고 판단하여 중복으로 사용처리를 진행하는 경우다.
JPA 는 기본적으로 락을 자동적용하지 않습니다. 명시적으로 지정하지 않는다면, 동시성 제어가 되지 않는다.
고로 조회 & 사용처리 로직에 트랜잭션을 걸고, 해당 행에 Lock(Row Level Locking) 을 걸어 동시성을 해결한다.
비관적 락을 이용한다면, 조회 시점에 조회 상품에 락을 걸고, 트랜잭션이 완료될 때까지 다른 요청이 해당 상품을 조회하지 못하도록 한다.
이후 요청은 사용처리가 완료된 상품을 조회하게 되고, 중복 사용처리가 되지 않을 것.
비관적 락을 걸게 되는 경우, 트랜잭션이 완료될 때까지 락을 걸기 때문에 트랜잭션의 범위를 최소화하는 것이 좋다.
만약, 트랜잭션 충돌 가능성이 낮다면, 락을 물리적으로 걸지 않는 낙관적 락을 이용하는 방법도 있다.
위 사례의 경우, 트랜잭션 경합 가능성이 높기 때문에 비관적 락을 이용해 동시성 제어를 진행해야 할 것으로 보인다.
'회고록' 카테고리의 다른 글
2024 10월 3째 주 (촉박한 프로젝트 일정속에서) (3) | 2024.10.20 |
---|---|
2024 10월 2째 주 (0) | 2024.10.13 |
2024 9월 4째 주 (결제 도메인의 추상화 보존기) (4) | 2024.09.29 |
2024 9월 3째 주 (나에게 한계를 넘어선다는 것) (1) | 2024.09.22 |
2024 9월 2째 주 (성장의 기로(리더십)) (0) | 2024.09.17 |