재고 차감 및 실제 주문 수량 계산 로직

[daadaadaah]

Conclustion

• v3

분산락(V2) -> 재고 사후 검증과 롤백을 활용하여 Lock Free 구조(V3)를 선택한 이유

• 작업을 복잡하게 만들고, 디버깅하기 어려운 분산락을 대신하여 분산락을 통해서 해결하고자 하는 문제를 재고 사후 검증과 롤백을 활용하여 Lock Free 구조로도 해결 가능하기 떄문이다.
• 분산락의 경우, 멀티쓰레드 환경에서 발생하는 버그들이 재현하기도 함들고, 특수한 케이스에서만 발생되기 때문에, 오랜 시간이 지나서야 결함을 발견할 수 있다. 또한, 설정한 락 임대하는 시간보다 실제로 더 걸려서, 로직이 다 수행하기도 전에 락이 해제되고 다른 쓰레드가 락을 잡게 될 경우, 개발자가 의도하지 않은 대로 로직이 진행될 수 있다. 따라서, 락 로직을 가능한 배제하는 것이 좋다.
• 이런 단점에도 불구하고, 분산락을 사용하는 이유는 데이터의 일관성을 유지할 수 있게 해주기 때문이다.
• 재고 데이터를 관리하는 Redis의 경우, 싱글스레드 기반이므로, 일반적으로 동시성 제어가 필요없지만, 나처럼 비즈니스 로직상 필요한 경우가 있다.
• 왜냐하면, 분산락을 통해 다음 로직들을 묶어줘야 했기 때문이다.

1. 재고 조회
2. 재고 검증
3. 재고 감소

• 만약, 묶어주지 않으면, 다음과 같은 상황에서 데이터의 일관성이 안맞는 문제가 발생한다.

/*
 * 1. [A 트랜잭션] 재고 조회 : 2개
 * 2.                                           [B 트랜잭션] 재고 조회 : 2개
 * 3. [A 트랜잭션] 주문량(2개) 만큼 재고 감소 : 현재 재고량(2) -> 차감 후 재고량(0)
 * 4.                                           [B 트랜잭션] 주문량(1개) 재고 감소 : 현재 재고량(0) -> 차감 후 재고량(-1) 개 // 🧨 차감이 되지 않아야 하는데, 차감 됨
 * /

• 결국, 재고 데이터의 일관성을 보장하기 위해 분산락을 사용하는 건데, 이 일관성을 "재고 사후 검증" 후 "rollback"을 함으로써, 재고 데이터의 일관성을 보장할 수 있기 때문에, 재고 사후 검증과 롤백을 활용하여 Lock Free 구조(V3)를 선택했다.

/*
 * 1. [A 트랜잭션] 재고 조회 : 2개
 * 2.                                           [B 트랜잭션] 재고 조회 : 2개
 * 3. [A 트랜잭션] 실제 주문량(2개) 만큼 재고 감소 : 현재 재고량(2) -> 차감 후 재고량(0)
 * 4.                                           [B 트랜잭션] 실제 주문량(1개) 재고 감소 : 현재 재고량(0) -> 차감 후 재고량(-1) 개 // 🧨 차감이 되지 않아야 하는데, 차감 됨
 * 5.                                           [B 트랜잭션] 실제 주문량(1개) 만큼 rollback // ✨ 차감되지 않아야 했기 때문에, 재고 원상 복귀 시킴
 * /

• 만약, 다른 트랜잭션에 의해 rollback을 했을 때, 재고가 생겨 "부분 주문"이 가능한 경우더라도, 그냥 예외 던지도록 한다. 기회는 한번 뿐...ㅎㅎ

트랜잭션(V1) -> 분산락(V2) 이유

• Redis 트랜잭션 대신 Redisson 분산락을 활용하여 재고 감소 로직 구현 #135 참고
• PR 할 때와의 로직이 바뀌었지만, 로직이 바뀌어도 동일한 이유로 분산락이 필요한 상황이다.