JPA - 카운트 문제 상황 빌드업

[haxr369]

DB 테이블 정의

시스템 구성

• 서버 : SpringBoot + JPA(Hibernate) : 1 to N
• DB : MySQL : 1 to N

시나리오

1. 1대의 서버에서 멀티스레드로 1대의 DB에 저장된 특정 카운터 업데이트하기 -> 경쟁 상태 유발
2. (1)에서 DB에서 제공하는 비관적 lock, 낙관적 lock을 이용해서 동시성 문제 해결
3. (1)에서 네임드 lock을 이용해서 동시성 문제 해결
4. 여러 서버에서 싱글스레드로 DB에 저장된 특정 카운터 업데이트하기 -> 경쟁 상태 유발
5. (2)에서 네임드 lock (분산lock)을 이용해서 동시성 문제 해결

왜 JPA를 사용할까?

1. 개발자가 SQL 쿼리 보다 객체 모델에 더 집중해야할 때.
2. 데이터베이스에 독립적인 페이징 API를 사용할 때.
3. 데이터베이스에 독립적인 락 추상화를 얻을 때.

참고

MySQL을 이용한 분산락으로 여러 서버에 걸친 동시성 관리

[ooMia]

e-commerce 도메인 접목

1. 웹 없이 멀티스레드로 진행
2. 상품 - 재고 - 결제 - 주문 - (Actor: optional)
3. 결제를 제외한 과정, Lock 기법을 활용하여 구현 @haxr369
4. 결제 서버 작성 @ooMia

트랜잭션 (주문 > 결제)

다음 내 단계의 작업은 모두 순서대로 성공해야 한다.

1. 주문 진행

• 주문 및 결제 정보가 확정된 상태

2. 결제 진행

• 가상의 결제 서버에 결제 요청

3. 결제 결과 STATUS_CODE

• 결제 성공: 200 OK
  • 성공했을 때, 고유한 결제ID를 함께 반환한다.
  • 임의의 결제ID에 대한 결제 취소 API를 제공한다.
• 결제 실패: 500 Internal Server Error

4. 주문 결과

• (1)의 정보에 따라 연관된 엔티티의 상태 갱신 및 검증

  • 주문 성공: 변경된 엔티티의 상태가 모두 유효하다.
  • 주문 실패: 적어도 한 개의 상태가 유효하지 않다.

Actor 페르소나

• Guest: 회원 정보가 없으므로 주문 불가
• Customer: 모든 회원은 주문 가능
  • InexperiencedCustomer: 1. 주문 준비는 느리지만, 2. 결제 완료는 빠르다.
  • LoyalCustomer: 두 과정 모두 빠르다.
  • ElderlyCustomer: 두 과정 모두 느리다.

[ooMia]

구현 상황 공유

• Feature/initialize spring-simple-payment#1

[haxr369]

Transaction 1

1. 사용자 권한 확인
2. 재고 확인
3. 주문 생성
4. 상품을 결제 중으로 상태 변환

Transaction 2

• 결제 결과가 성공일 때,

1. 상품 상태를 SHIPMENT 로 변경
2. 주문의 상태를 FINISH 로 변경

• 에러가 발생하거나, 결제가 실패했을 때,

1. 상품의 상태를 PENDING_ORDER 으로 변경
2. 상품 재고를 원복
3. 주문의 상태를 FAIL 로 변경

Transaction 3

1. 리디렉션 정보에 따라 주문을 읽기

트러블 슈팅

위에 그림처럼 각 색을 가진 세션이 순서대로 실행돼야한다.
동시성 제어가 되지 않는다면, 순서를 지키지 않고 작업이 실행되는 문제가 있다. 예를 들어 Tx1이 커밋 되기 전에 Tx2에서 주문을 읽으려고 하는 등 문제가 있다.
현재는 Tx2에서 롤백되는 부분과 Tx3에서 주문을 읽으려고하는 부분이 겹쳐서 문제결제가 실패했을 때 결과를 받지 못한다.