트래픽 패턴에 대한 분석
장바구니는 선착순 이벤트처럼 짧은 타임에 몰려오는 구조가 아님
따라서, 서버입장에서 부하를 느낄 여지가 아예 없음
브라우저 경우 브라우저마다 세션이 다르게 잡히고
서버 세션도 다중인스턴스 문제로 레디스를 쓸 수 밖에 없게 됨
레디스 자체도 휘발성이라 서버 재시작되면 증발함
어지간하면 재시작될 일이 없긴한데 처음부터 구조적으로 좋지 않음
그리고 캐시는 가능하면 개별적인 데이터가 아니라
전역적인 데이터에 대해서 하는게 바람직함
장바구니는 개개인마다 다 다르게 잡히는데 100만명이 장바구니 담으면
메모리에 100만개 데이터를 유지해줘야함
회원 수만큼 메모리가 늘어나는 구조가 설계 미스
데이터베이스 테이블에 저장하고 오래된건 배치로
일정기간 지난건 주기적으로 지워주면 아무런 문제 없음
트랜잭션에 대해 락이 잡히더라도
장바구니 레코드마다 ROW레벨 락이 잡혀서 락으로 인한 병목 없음
단일 insert 문을 부하를 너무 고평가하는데 1~2ms 정도면 처리됨
그러면 어떤 경우에 레디스를 쓰면 이득일까요???
"장바구니 담은 인원"
1. 실시간성이 덜 중요함, 정합성이 덜 중요하고 원장 데이터가 아닌 집계데이터임
2. db입장에서는 상품페이지에서 카운트쿼리가 많이 날라가 cpu 소모가 큼
3. db에서 상품칼럼에 담은 수를 매번 update +1하면 이것은 개개인이 아닌 상품에 대한 전역 데이터에 락을 잡게 됨
이 경우엔 상품 레코드에 락을 잡게 되어 다른 상품 업데이트 쿼리를 지연시킬 수 있음
(물론 테이블 분리하면 해당 문제가 덜합니다)
실무자에서 바라보는 시각을 전달드렸습니다.
감사합니다.
지피티로 가독성 향상
아하 좋은 답변 감사합니다 아예 생각도 못해본 방향이네요
좋은 피드백이네 바쁠텐데도 나도 참고가 됐어