[플러스백엔드] 4주차 발제(하헌우 멘토님)

[하헌우 코치님 과제 Summary]

 

[E-커머스 과제]

1. 주문 결제할 때 Order Table, Order Item Table이 사실상 필수도.

2. ERD, 시퀀스 다이어그램 => 노션 머메이드 툴로 사용한다

3. 시스템 아키텍쳐 => 이레이져로 하면 멋있게 나온다.

4. PG연동 <= 어렵다

 

[문서작성 능력 중요하다??]

1. 문서작성 능력이 코딩보다 중요할 수 있다.

2. ERD, 시퀀스 다이어그램 너무 중요하다. ReadMe에 제발 넣어라.

3. 말하기 = 쓰기 > 문서작성능력 > 코딩능력

 

[콘서트 예약 과제]

대기열은 어떤 부하를 낮추기 위해서 작업하나...?

= DB 부하!(서버 부하X)

 

2. 좌석에 접근할 수 없도록 하는 경우 락을 사용하는데 

실제 현업에서는 안정성을 위해서 비관적락을 사용하는 편이다.

낙관적락은 오류의 가능성이 존재.

 

3. 도메인은 무조건 테스트를 빡빡하게 할 수 있어야 한다.

DDD는 추세다.

 

4. 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가 없도록 한다

=> DB 없이 어떻게 할 수 있을지 고민해보기... 뭔가 할 때는 제약사항을 설정하고 생각해보는 것도 좋은 방법

 

5. 임시배정은 구현 방법이 다양

1) 테이블의 상태값을 변경하는 것

2) Redis를 이용해서 하는 것

3) 1번 ,2번의 장점만 취하는 방법이 있다=> 이게 뭐지?

* 대기열 구현시에 DB로 구현하면 @Schedule로 구현하다보니 일정 주기마다 사용자의 대기열상태가 갱신된다.

그렇다보니 이 갱신 주기가 되기 전까지는 완전 실시간으로 상태값이 반영되지 않는다.

* 반면에 Redis는 TTL을 즉각적으로 반영한다. 사실 내부적으로 Redis도 스케쥴러를 사용하는데, 어떻게 ttl을 만료시점 즉시 상태값을 변경시켜주고, DB는 그렇게까지 못하는지를 생각해봐라.

 

DB도 없고, 레디스도 없는 상황에서 좌석예약요청 API를 어떻게 구현할지 생각해보기!!

 

 

6. 임시배정 해제 방법

- 스케쥴러를 사용해서 하면 된다

- 단점은 실시간으로 안될 수 있다 => 왜냐하면 주기적으로 하기 때문이다

 

[주문결제 구현 방식]

아이템 -> 장바구니 (n개) -> checkout -> 결제페이지 -> 결제 정보를 입력

(주소, 결제 수단 선택) -> 결제하기

 

- 무신사 결제버튼 누르면 카드사 나와있는 결제창이 뜬다.

   이 결제창은 무신사것이 아니라 토스 사이트가 팝업으로 뜨는 것이다.

    무신사 서버 내에 결제사 SDK가 깔려있다.

- 결제 하기 누르면 카드번호나 아니면 토스 결제 같은 경우 휴대폰 번호 누르면

- SDK 화면 -> 토스 서버로 결제 요청 -> 토스 서버가 -> 사용자 휴대폰으로 푸시 보내고 -> 사용자가 생체인증 통해서 결제

-> 다시 휴대폰 -> 토스서버 결제 완료 -> 토스 서버에서 결제정보 저장 상태 -> 리다이렉트 url로 요청을 보내준다. "v1/toss/payment" v파라메터에 뭐가 담기냐?

 

파라메터

- 결제수단, 결제 금액, 결제 키, 식별 키

토스 -> "v1/toss/payment" {

   1. 주문 생성

   2. 재고 차감(비동기)

   3. 포인트 추가(비동기)

   return "결제 완료"

}

 

10개 중에 9개 팔려서 1개 남았어

 

[먼저 어떻게 구현할지 시퀀스 다이어그램, 플로우 검증]

1. 구현하기 전에 플로우와 시퀀스 다이어그램으로 검증

2. 컨펌을 받으면 그대로 코딩하면 원하는대로 작동해야 한다.

 

[4주차 발제]

1. MVCC 개념을 모르면 공부해보기

2. DB마다 트랜잭션 격리 레벨 수준을 알 수 있다.

 

[트랜잭션 격리 수준]

1. JPA를 사용하면 Repeatable read를 보장해준다.  => Propagation

2. 격리레벨은 db마다 다르고 3~6단계

3. 면접 질문 대답 예시 : 컨텍스트 한정 격리레벨이 DB마다 3~5단계별로 다 다른데, MYSQL 기준으로 알려드릴까요?

 

@Transactional() <- 격리레벨 설정 안함

@Transactional(propagation.required) <- 격리레벨 설정

 

 

비관적 락을 사용하면 조회도 락이 걸려 불가능하기 때문에, DB 큐에 쌓이고

그러면 서버도 계속 기다린다. 그렇다보니 DB가 터져버린 서버도 터진다.

 

 

[인덱스에 대한 설명]

인덱스를 추가하면 쓰기 부하가 생긴다. 왜냐면 원장 + 인덱스 테이블에도 기록 해야하니까 + 디비 입장에서는 인덱스테이블은 메모리에 띄워놓아야합니다.

 

- 인덱스를 사용하면 어떤 DB 부하가 감소하나?

읽기 시에 CPU, 메모리 자원을 절감할 수 있다는 것에서 장점이 있다

하지만 쓰기, 수정시에 성능하락의 가능성이 있다. 그 이유는 인덱스도 조정이 해야하기 때문이다.

 

그럼 언제 필요할까?

- 데이터가 너무 많아 조건에 맞게 조회하는 데에 속도가 오래 걸리는 경우(카디널리티가 높은거)

==> 카디널리티가 높다? 데이터의 다양성이 높다.

예를 들면 데이터 10만개가 있는데, 데이터의 종류가 남자, 여자이다. 그러면 사실 인덱스를 거는 의미가 없다.

 

- 인덱스만으로 데이터를 찾을 수 있는 경우

- 읽기 성능을 좋게 하려면 읽기에 부하를 줄이고, 쓰기에 부하를 높인다.

- 반정규화 : 읽기 성능 높아짐, 정규화 : 쓰기 성능 높아짐

-

 

[Q&A 시간]

1. 배타 Lock 개념

 배타락은 기본적으로 조회가 되지 않는다.

하지만 MVCC로 인해서 커밋 되기 이전의 데이터를 조회가 가능하다.

 

2. 격리레벨에 대해서 공부하기

 

3. 사가 패턴

 

4. 레퍼런스는 어디서 확인?

github에서 유명한 레포지토리를 300~400개를 보니까

본인만의 좋은 패키지 구조가 생겼다.