DB 대기열 접근 방식 (from. 학습매니저님)

대기열을 구현하잖아요.대기열의 목적) ==> 데이터베이스 커넥션 수는 한정되어 있다. <== 커넥션 수 넘어가면 터지겠죠.그래서 항상 "로그인"이 제일 먼저 터진다. 어차피 APi 쓰기도 전에 터진다.  OK===100,000 -> 99,999 -> 99,998100,000 -> 98,034 -> 87,506대기열 => 구현방식 2개- 은행 창구 처럼 돌아가는 거
    - 이거는 뭘까요?
    - 번호표가 있고, 창구 수가 제한되어있죠. 은행가면
    - 그런 흐름으로 구현하느 거 하나
    - 얘는 대기열 / 참가열 같이 구현할 수있음 .
    - 대기 좌석에 있느 사람 + 창구 좌석에 있느 ㄴ사람
    - => 대기 정보를 좀 빡세게 구해야함 => 대신에 구체적으로 구할 숭 있음
- 회전 목마처럼 돌아가는 것
    - 놀이공원 가면 줄서잖아요.
    - 근데 한명씩 들어가요?
    - 뭉탱이로 들어가잖요. 놀이공원 그 기구가 한 사이클 다 끝날때까진 몇명이 들어가있던 기다려야 되잖아요.
    - 일단 10명씩 들여보내준다. 근데 앞에서 2명 먼저 끝났다고, 이 2명을 들여보내 주진 않음.
    - 무조건 10명씩 처리
    - 얘는 하나만 써도 된다. 오버엔지니어링 피할 수 있음
    - 대신 대기 시간은 더 길어진다.
    - => 이거의 장점 ))))) 대기 정보를 쉽게 구할 수 있음. 대신에 러프하게 구할 수 있음

 

 

놀이공원식으로 개발한다?

공식을 활용할 수 있다.

입장 가능한 시간을 구할 수 이써요...

const 놀이공원이 돌아가는 시간 = 10분; <- 이라고 가정 했을 때,

var 대기열에 들어온 순서 = 앞에 놈들 카운트 + 1;

var 분당 처리량 = 놀이기구 하나에 입장할 수 있는 인원 수;

var 입장 가능 시간 = 현재 시간(토큰이 생성된 시간) + ( 대기열에 들어온 순서 / 분당 처리량) * 놀이기구 돌아가는 시간;

 

SELECT 입장 가능 시간 FROM 대기열 WHERE 무슨 조건;

쿼리 한 번으로 검증할 수 있음. .

 

참고

https://kyulog.hashnode.dev/hhplus-backend-wil-5

 

 

• 은행창구식
  • 은행 갔을 때 대기 번호를 뽑잖아요
  • 한 명씩 들어가는데
  • 대기 좌석이 있고, 창구 좌석이 있다
  • 그래서 이거랑 유사하게 돌아간다.
  • 대기열 / 참가열이 있다.
  • 열을 두 개 둔다.
  • 한 명이 끝나면 띵동 울리면서 창구로 이동
  • 대충 이런 방식 (창구로 이동하면 서비스 이용할 수 있음)
• 놀이공원식
  • 우리가 놀이공원을 갔다.
  • 놀이기구를 타려고할 때
  • 줄을 섭니다.
  • 이 때 한 명씩 들어갑니까?
  • 여러명씩 한 번에 들어간다.
  • 그리고 들어 갔어요. 근데 인원이 다 안채워져있어도 놀이기구 운행은 되죠?
  • 10명 맥시멈인데 줄에 8명밖에 안서있으면 일단 8명 들여보내고 운행을 합니다.
  • 그리고 나서 나중에 찾아온 사람들이 있는데, 안들여보내주죠.
  • 운행 중이니까
  • 이런것처럼 뭉탱이로 한 사이클에 들여보내고, 뒤에 후순위들은 무한정 대기 시킨다.
  • 는게 놀이공원식입니다.
  • 여기서 질문 받겠습니다.
  • 구체적으로 질문해주세요.

은행 창구식 장/단점 )

• 맞습니다. 실시간성이 어느정도 보장됩니다.
• 실시간성이 보장 된다?
• DB로 구현하면 부하 포인트가 늘어난다.
• 왜? 실시간 보장해야 하니까. 계속 쿼리를 날려서 검증해야 한다.

놀이 공원식 장/단점 )

• 엄연히 실시간이 아니어도 된다.
• 왜냐면 들여보낼 수 있는 시간이 정해져 있다.
• 그 시간에만 쿼리를 날리면 된다.
• 기준) 놀이기구가 운행 시작해서 끝나는 한 Term 시간이 기준
• 유저마다 예약을하고 결제하는데 까지 걸리는 시간이 다 다를수 있음
• 누구는 빨리하고, 누구는 느리게 해요.
• 근데 이거를 상관하지 않고, 네
• 맥시멈을 정해놔서 그 시간 동안에 못하면 더이상 서비스에 못하고
• 다시 대기열을 타야합니다.

 

그럼 검증해서 들어온 애들이 퇴장해야할 시기가 없으면 커넥션 풀 터지죠.

그래서 맥스타임(= 놀이기구 하나가 끝날때 까지 걸릴 시간) 을 설정 해야 놔야 한다......

안그러면 계속해서 서비스를 있게 되잖아요.

그러면 뒤에 있는 애들이 특정 시점에 커넥션 풀 터져서 서비스 이용을 못할 수도 있어요.

 

RDB로 했을 때 대기순서를 알려면 카운트를 두긴 해야 합니다.

아니면 오토인크리먼트 써야 하는데............ <-- 만약에 오토인크리먼트된 결과를 가져와서 써야하는 순간이 있다면 조회 쿼리 이라서.......... 그래서디비할 때는 순서를 알아야 되잖아요.

대기 정보를 사용자한테 제공하려면 +1

 

맞아요.

저는 들어있는 애 세는걸 선택하긴 했어엇용...

그리고 대기순서랑 남은시간은 정확할 필요는 없습니다.

정확성 <--- 어느정도 그래도 보장하고 싶다하면 은행창구 편하긴 함

얘는 만들 때 앞에 애들 지우고 뭐하고 할거 아니에요. 그쵸 서비스 이용끝난 애들 지우고 + 이용중인 애들 세고

그러면 어느정도 정확하겠죠?

놀이공원식 <-- 뭉탱이로 들여보내고 누가 끝나던 상관없이 운행 시간을 지켜야함 <-- 앞에 몇-명이 이용끝났는-지 몰르니까 정 확히 셀수 없음 --> 많은 것들을 "알빠? " 하는 방식입니다. --> 매우 불친절한 방식

 

과제니까 Fixed 방식 ) 보통 그냥 서비스 이용하는데 너무 긴 대기시간이면 , BTS급 콘서트 아니면 나 안해 하고 나갈 수도 있으니까 적당히 잡으세요. (5분 10분 줘요 ㅋㅋ)

현업에서는 Flexible하게 동적으로 평균 시간 계산 )

• 각 요청 별로 토큰이 서비스에서 퇴장할 시간 - 입장 가능한 시간
• 평균을 내서
• 한 사이클이 돌아가는 시간을 동적으로 변화시킬 수 있는데,
• 만약에 11번 유저까지 5분간 이용하다가 , 12번 이후부터는 2~3분 이용하게 바뀜
• 그럴 떄 어떻게 되까요? 앞에 있는 애들이랑 점점 입장 가능 시간이 겹치는 시간이 찾아오게 됩니다.
• 그래서 101번~120번 들어와서 하는데, 뒤에 있는 애들이 얘네랑 겹쳐서 ㄱ같은 시간에 이용할 수 있게 된다면?
• FIFO 아니겠죠?
• 그래서 동적으로 하면 어떻게 FIFO 에 가깝게 처리할 수 있을까 고민해야한다.