순간적인 대량 트래픽 소화 선착순 주문 이벤트 진행
📍문제점
- 평소 트래픽 10배가 들어올거라고 예상 ( 실제로는 150배 예상하지 못한 트래픽이 들어온다!!)
- 주문 뒤에는 PG사가 있다 PG사에서 에러가 터질 수도 있다.
📍해결방안
처리할수 있을만큼만 순서대로 입장시켜라!!
(모든트래픽을 차례차례 순서대로 우리가 처리할 수 있을만큼만 들여보내자)
큐 시스템
- 기능
- 모든 이벤트 대상에게 번호표 발급
- 번호표를 발급받은 사용자를 줄을 세운다 (대기열)
- 대기열의 사용자에게 현재 몇번째 대기순서를 알려준다.
- 서버가 소화할 수 있을 만큼 사용자를 입장(참가열)
- 고려사항
- 고성능 처리 가능 (Redis)
왜 레디스?
- 많은 서비스에서 사용하는 검증된 저장소
- 입/출력이 빠른 In-Memory 데이터베이스
- 다양한 자료구조 지원, 요구사항을 쉽게 해결 가능
📍대기열 - Sorted Set
sorted set → 데이터를 추가할 때 스코어를 부여할 수 있고 스코어에 따라 정렬 한다.
요청이 들어오면 요청이 들어올 때의 TimeStamp를 스코어로 부여해 요청들어온 순서대로 정렬
- 이벤트 주문을 요청한 순서대로 처리
- → ZADD - 데이터 추가시 부여한 스코어에 따라 정렬
- 대기중인 사용자에게 현재 대기 순번을 제공
- → ZRANK 라는 명령어 사용 → 현재 순위 조회
- 일정한 수만큼 대기열 → 참가열 이동
- → ZRANGE - 일정한 수만큼 리스트 조회
📍레디스 사용시 고려사항
- KEY 명령어 사용금지싱글 스레드
- 풀스캔, 시간복잡도 O(n) → 데이터가 많아지면 많아질 수록 성능은 떨어진다.
- 각 명령어의 시간 복잡도 확인데이터가 많아질 수록 성능 저하
- Sorted Set의 경우 시간복잡도 O(log(n))
📍주문 라우터 ( 이벤트 서버 ,일반 사용자서버 격리)
- 주문 시스템으로 요청 들어오는 출입구
- RULE 에 따라 API HOST를 변경할 수 있는 라우팅 서버
- RULE은 회원번호,업소번호,지역코드로 서렂ㅇ
- WebFlux + Netty 논블로킹 서버
- 10000 TPS 거뜬히 처리
생각정리
배민의 선착순 이벤트의 트래픽을 견디기 위해
중간에 큐 시스템을 레디스를 이용해 개발 → 대기열을 구성해 처리할 수 있을 만큼씩 받아 처리한다.
또한 주문 라우터를 이용해 일반 주문과 이벤트용 주문을 각각 구별하여 격리
이벤트용주문 서버에 장애가 발생하여도 일반 주문자 서버에는 영향이 없도록 구성
댓글