3. Technical Issue - tastingcode/standard GitHub Wiki

✅ 동시 주문 처리하기

1. 상품 동시 주문
   • 👉 상품 동시 주문 테스트
2. synchronized 선언
   • 👉 주문 처리 동기화
3. Facade Layer 주문 처리
   • 👉 기존의 synchronized를 지우고 Facade Layer의 주문 처리 로직에 synchronized 선언
4. 낙관적 락 모드 적용
5. 결론 - 동시성 이슈 해결
   • 👉 Issue Posting

---

1. 상품 동시 주문

• 다음과 같은 상품을 20명이 동시에 5개씩 구매한다면 결과는 어떻게 나올 것인가?

상품명: A 재고: 100

👉 상품 동시 주문 테스트

결과 : 20개의 주문 처리 중 3건만 처리됨

2. synchronized 선언

• 주문 처리 로직에 synchronized를 선언하면 정상적인 재고 처리가 가능할 것인가?

👉 주문 처리 동기화

결과 : 처리할 수 있는 주문의 양은 늘었으나 여전히 동시성 이슈를 해결하지 못함

🚫 여전히 동시성 이슈가 발생하는 이유는 트랜잭션의 동작원리에 기인한 것이다.

---

📌 @Transactional의 동작원리

1. @Transactional이 적용된 클래스는 CGLIB에 의해서 클래스 기반 프록시가 생성된다.
2. 해당 로직으로 진입하기 전/후 AOP Proxy를 통해서 다음과 같이 트랜잭션의 시작 및 커밋/롤백이 진행된다.

3. 주문처리 로직에 synchronized가 선언되어, 먼저 도착한 쓰레드가 해당 로직을 처리할 때 Monitor Lock을 획득하게 된다.
4. Lock을 획득하지 못한 나머지 모든 쓰레드들은 Lock을 획득하기 위해 대기한다.
5. 위 그림과 같이 Thread-1 이 로직을 마치고 커밋/롤백 시점으로 진입하는 그 순간 다음 쓰레드가 Lock을 획득하고 로직을 수행한다.
6. 이 때 Thread-1이 commit되기 전이므로 특정 상품의 재고처리가 이루어지지 않은 채 Thread-2의 주문처리가 진행된다.

🚫 위와 같은 이유로 동시성 이슈가 발생하고 있는 상황이다.

---

3. Facade Layer 주문 처리

• 트랜잭션의 동작원리에 기인한 동시성 이슈가 발생하지 않도록 Facade Layer에서의 주문 처리

👉 기존의 synchronized를 지우고 Facade Layer의 주문 처리 로직에 synchronized 선언

결과 : Facade Layer에서 주문 처리 서비스를 호출하여 동시 주문 처리를 모두 정상적으로 수행함.

---

4. 낙관적 락 모드 적용

• 임계 영역만 제한하는것이 아닌 메서드나 코드 블록을 동기화 하는 것은 다음과 같은 이유로 성능 저하가 우려된다.
  • 락 경합 : 여러 스레드가 동일한 synchronized 블록에 진입하려고 할 때 경합이 발생
  • 스레드 대기 : synchronized 블록에 진입하지 못한 스레드는 대기 --> 리소스 낭비와 대기 시간 증가

위와 같은 이유로 다음과 같이 구조 변경

• 쇼핑몰 특성 상 동시 주문 요청에 따른 잦은 트랜잭션 충돌이 일어날 것으로 보이지 않음
• synchronized ➡ @lock-optimistic

5. 결론 - 동시성 이슈 해결

✅ 결론 : 위와 같이 상품 조회 시 낙관적 락 기법을 사용하여 트랜잭션 간 격리성 보장으로 동시성 이슈를 해결함

👉 Issue Posting

---

✅ 카테고리를 어떻게 관리할까?

1. 카테고리 설계
2. 데이터베이스로 관리❓🤔
3. Enum으로 관리❗😄
   • 👉 Enum : Category
4. Json으로 변환 😎
   • 👉 @Service : CategoryService
5. 결론 - Enum으로 관리

---

1. 카테고리 설계

• 상품 카테고리를 다음과 같이 설계
  • 카테고리 별로 depth를 가질 수 있다.
  • 상품의 추가는 마지막 카테고리(리프 카테고리)에서만 할 수 있다.
  • 상품을 카테고리로 조회할 수 있다.
  • 카테고리 조회 시 하위 카테고리 조회결과를 포함해야 한다.

2. 데이터베이스로 관리❓🤔

• 카테고리를 데이터베이스로 관리할 수 있기는 한데...

🚫 다음과 같은 문제점들이 존재함

1. 클라이언트의 요청마다 매번 데이터베이스에 접근해야 한다.

   • 트래픽이 많은 서비스라고 가정할 때, 카테고리에 속해있는 데이터를 가져올 때 매번 복잡한 쿼리 조회로 인한 성능 저하를 일으킨다.

2. RDB 테이블이 카테고리 계층형 구조를 표현하기에 적합하지 않다.

   • 계층 구조를 표현하기 위해 depth, 부모, 자식 카테고리의 값 등의 메타데이터가 컬럼으로 존재해야 한다.
   • 이는 계층 구조 파악 및 원하는 카테고리에 접근하는 데 있어서 쿼리의 복잡도를 증가시킨다.

3. 기타

   • 상품과 상품카테고리 테이블의 조인 발생으로 인한 성능 이슈
   • 코드 레벨이 아닌 데이터베이스 레벨에서 카테고리 관리 등

---

3. Enum으로 관리❗😄

• 다음과 같은 이유로 Enum으로 관리
  • 카테고리는 변경될 일이 거의 없음
  • DB를 통해 접근하지 않음으로써 성능 향상
  • 개발 및 운영 시 한 눈에 전체 데이터를 확인 가능

👉 Enum : Category

---

4. Json으로 변환 😎

Enum 타입의 카테고리를 Json으로 변환하기 위해 다음 과정을 수행한다.

1. ObjectMapper를 사용하여 JSON 노드 생성
2. 기본 속성 추가 - code, name
3. 하위 카테고리를 재귀적으로 처리

👉 @Service : CategoryService

반환되는 CategoryNode는 다음과 같이 3차 계층구조를 가지고 있다.

5. 결론 - Enum으로 관리

✅ 결론 : 정적 데이터에 가까운 카테고리를 테이블이 아닌 Enum을 활용하여 다양한 이점을 얻을 수 있다.

---

✅ 페이징 처리 재사용하기

1. 페이징 처리 고민
2. 페이징 처리 설계
3. 페이징 처리 구현
   • 👉 PageResultDto
4. 페이징 처리 테스트
   • 👉 Method : getReviewList
   • 👉 Test : getReviewList
5. 결론 - 다형성 구현

---

1. 페이징 처리 고민

• 데이터 페이징 처리를 템플릿화 할 수 있을까?
  • 일반적으로 웹에서 데이터들을 조회할 때 대부분 페이지 정보가 포함되어 있다.
  • 재사용 가능한 페이징 템플릿을 만들면 다양한 곳에서 활용될 수 있다.
  • ✅ 순수한 엔티티의 데이터 페이징 처리를 템플릿화 하여 상품평을 조회해보자!

2. 페이징 처리 설계

• 페이징 데이터는 dto 목록과 페이징 정보를 가지고 있다.
• 다양한 타입의 엔티티를 dto 목록으로 변환할 수 있어야 한다.
• 재사용을 위해 제네릭과 Function 객체를 적극 활용한다!

---

3. 페이징 처리 구현

다음과 같이 PageResultDto를 구현할 수 있다.

• 다형성을 구현하기 위해 제네릭과 함수 객체를 사용한다. 👉 PageResultDto

---

4. 페이징 처리 테스트

페이징 처리된 상품평들을 조회하기 위해 아래와 같이 진행한다.

• 상품정보와 pageable을 이용해 페이징 데이터를 조회한다.
• 엔티티를 dto로 변환하는 함수 객체를 사용한다.
• 페이징 데이터와 함수 객체를 이용하여 PageResultDto를 생성한다.

👉 Method : getReviewList

PageResultDto를 사용하여 상품평 조회 테스트 결과 모두 정상 통과하였음을 확인할 수 있다. 👉 Test : getReviewList

---

5. 결론 - 다형성 구현

✅ 결론 : 다음과 같이 다형성을 구현한 PageResultDto을 사용하여 상품평을 조회할 수 있다.

---