오늘은 집가서 롤 해야지(할 수 있겠냐?) 회의 (2023‐08‐25)

우리 서비스 현재 문제점 분석

• select 및 insert Lock 관련 이슈
• 장바구니 추가 로직 동시성 이슈
• 주문 내역 조회 속도 이슈
• 상품을 주문하는 과정에서 그 상품 조회

스케줄러(배치) 이슈

• 하나가 죽으면 다 죽는다.
  • 동기에서 비동기로 작업을 변경하면 해결할 수 있다.
  • 작업마다 로그를 제대로 찍어서 어디서 이슈나는지 확인할 수 있게 만들어주자!

주문 병목 이슈

• 주문 시 결제 API 요청에 의해 병목이 너무 심함
• 상품 정보 및 상품 수량이 한 테이블에 있어 조회/수정이 한 테이블에 들어가게 되어 문제발생

결제 관련 처리, 상품 락도 처리가 필요함

단 한명을 위한 vip 서비스

결제 → 외부 api → 대처가 빡세야할 것 같다.

조회 시나리오 추가 및 성능 향상

상품 조회 시나리오 제안

• 판매량 순 메인 노출 (인기 Best)
• 키워드 검색

성능 향상

• 상품 검색
• 판매량 순 정렬
• 주문내역 조회
• 상품 상세 조회

판매량을 어떻게 기록할 것 인가?

1. 실시간 판매량으로 조회 (데이터 정합성 이슈)
2. 일일 판매량으로 조회 (Stock 정합성 배치 돌릴 때 주문 상태를 바탕으로 기록 가능)

판매량 집계 방법에 대한 고민

배치 처리 할 때 판매량을 찾을 수 있다. → 그러나 판매량을 찾는 과정에서 예외가 터지면 트랜잭션이 롤백되어 배치 처리가 터져버리는 문제가 발생할 수 있다.

이에 대한 해결 방안을 찾아야하는데 현재 생각한 해결 방안은 다음과 같다.

1. 비동기 처리 → 서버 성능 상 힘듦

2. 트랜잭션 전파 (전파 속성 잘 걸어서 해결해보기)

3. 로직 분리 (트랜잭션 서로 안섞이게 만들기) → try-catch 로 잡기

4. 일일 판매량 순 조회는 기본이다.

insert into products(name , image_url , price, status , quantity ,created_at , updated_at ) values('test5' , 'test5' , 100000 , 'IN_STOCK' , 100, now(),now());
insert into product_sales(product_id , sale, sale_date , created_at , updated_at) values(4,50,'2023-08-24',now(),now())
insert into stocks(expiry_date , product_id , quantity, stock_type , created_at ,updated_at) values('2023-09-26',1,100,'NORMAL',now(),now())

select * from products p left join product_sales ps on p.id = ps.product_id 
where p.id > 0 
order by ps.sale desc;

product_sales에 product_id와 날짜에 유니크 걸어야된다. -> 중복 데이터 문제가 발생할 수 있음

1. 스케줄러 비동기 처리
2. 커서 기반 리팩토링
3. 성능 측정하기
4. 메모리 캐시 적용해보자!
5. 상품 조회랑 쓰기 사이의 분리